Hackerbot-Claw: AI-Driven Pull Request Exploits in GitHub Actions CI/CD

Date Observed: Late February 2026

Ecosystem: GitHub Actions CI/CD

Attack Type: Pull-request triggered workflow exploitation → Remote Code Execution (RCE) → Token theft

Key Takeaways:

• Hackerbot-Claw exploited misconfigured GitHub Actions workflows using malicious pull-request (PR) input.

• The attack executed inside the CI/CD build environment, not in merged code.

• Once tokens were exposed, attackers could modify repositories and publish artifacts.

A recent campaign attributed to the GitHub account “Hackerbot-Claw” targeted open-source repositories by exploiting misconfigured GitHub Actions workflows.

Public reporting indicates that the bot automatically scanned tens of thousands of repositories searching for workflows that executed unsanitized pull-request input. When a vulnerable workflow was found, the attack used untrusted PR data to achieve code execution inside the CI runner.

Once execution occurred in the build environment, repository tokens could be exposed and then used to modify repositories, delete releases, or publish malicious artifacts.

Figure: Hackerbot-Claw attack progression

Scope and Impact of the Attack

Scope

• 7 high-profile repositories targeted

• 4 repositories reportedly compromised

• Remote code execution confirmed in multiple cases

Affected repositories included projects associated with major organizations such as Microsoft, Datadog, and Aqua Security.

Impact

Public reports describe several forms of repository disruption following token exposure:

• Repository mutation (renaming or making repositories private)

• Deletion of releases

• Malicious artifact publication

• Exposure of repository access tokens

In the most severe case, Aqua Security’s Trivy repository was fully compromised via a stolen Personal Access Token (PAT). The attack privatized the repository, deleted all GitHub Releases, and pushed a malicious commit before access was restored.

How the Attack Works (CI/CD Perspective)

Step 1: Repository Scanning

The bot scans GitHub repositories for workflows that:

• Use pull_request_target triggers, which check out forked code with elevated permissions

• Allow any GitHub user to trigger execution via issue_comment with no authorization checks

• Interpolate ${{ }} expressions directly into shell commands without sanitization

• Pass unsanitized pull-request metadata into shell contexts

• Run with write-scoped tokens granting commit, release, or artifact publishing access

These conditions create an opportunity for untrusted input to influence CI execution.

Step 2: Malicious Pull Request

A pull request is opened containing a trivial change to appear legitimate.

The malicious payload is embedded in fields consumed by the workflow, such as:

• Branch names containing shell command substitution syntax

• Filenames containing base64-encoded payloads

• Source code files with injected functions that execute automatically (for example, Go init())

• Pull request metadata passed unsanitized into shell commands

In some cases, public reporting also showed attempts to abuse AI-agent context and instructions inside repository workflows. If the workflow inserts these values into shell commands without sanitization, attacker-controlled input becomes executable.

Step 3: Remote Code Execution in the CI Runner

When the workflow runs, the payload executes inside the CI environment.

At this point, the attacker gains:

• Command execution in the runner

• Access to environment variables

• Access to repository tokens used by the workflow

Step 4: Token Exfiltration and Repository Manipulation

Once tokens are exposed, attackers can use them to perform actions such as:

• Pushing commits

• Modifying repository configuration

• Deleting releases

• Publishing malicious artifacts

The compromise occurs during the build process, before any code is merged.

Why This Matters to Build and Security Teams

From a CI/CD perspective, this attack class exposes three critical pipeline risks.

Untrusted triggers executing privileged workflows

Workflows triggered by pull requests can execute code derived from untrusted inputs.

Excessive token permissions

Build jobs often run with repository tokens that allow write operations such as pushing commits or publishing releases.

Unrestricted network access

CI runners frequently allow outbound connections, enabling stolen tokens or secrets to be transmitted externally.

When these conditions exist simultaneously, a CI pipeline becomes a high-value attack surface.

Traditional defenses do not address this stage of the attack. Static code scanning does not detect runtime input manipulation. Secret managers do not prevent secrets from being exfiltrated once exposed. Code review happens before execution, while the breach occurs during execution.

The failure point is the build environment itself.

How InvisiRisk Helps Reduce Exposure to This Attack

Attacks like Hackerbot-Claw succeed only if two things happen during the build process:

1. Sensitive credentials are exfiltrated from the build environment.

2. Repository or artifact systems are modified using those credentials.

InvisiRisk is designed to reduce exposure to both at build time.

The InvisiRisk Build Application Firewall (BAF) operates inline within the CI pipeline between source retrieval and artifact publication. It monitors network connections, repository operations, and outbound behavior during build execution, helping teams detect and control suspicious activity before it becomes a downstream incident.

Defense 1: Secret Exfiltration Detection

InvisiRisk monitors outbound network activity during builds and detects attempts to transmit sensitive tokens or credentials.

If a workflow attempts to send repository tokens or environment secrets to an external endpoint, the connection can be blocked and the build execution can be stopped.

Defense 2: Blocking Unauthorized Outbound Connections

CI pipelines rarely need to communicate with newly registered domains or unknown infrastructure.

InvisiRisk enforces network policies that can block suspicious outbound connections originating from build jobs, reducing the risk that attackers can retrieve payloads or exfiltrate data.

Defense 3: Limiting Unauthorized Repository Modification

InvisiRisk monitors write-back operations from the CI environment.

Unauthorized attempts to push commits, modify repository configuration, or publish artifacts can be flagged or blocked before they reach GitHub or artifact registries.

Operational Security Outcomes

When these controls are in place:

• Secret exfiltration attempts can be blocked.

• Suspicious outbound fetches can be interrupted.

• Repository modifications from compromised builds can be prevented.

• The attack can be contained inside the CI environment.

The DevOps team receives an alert and can rotate credentials if necessary, with greater confidence that:

• Secrets did not leave the build system.

• No downstream environments were affected.

• No malicious releases were published.