Autonomous “Hackerbot-Claw” Exploits GitHub Actions Flaws, Targets Major Open-Source Repositories

CyberDefender 10 mins0

In February 2026, the software supply chain saw a new kind of attacker: an autonomous adversarial agent scanning and exploiting open-source repositories without human intervention.

The campaign, attributed to an automated bot named Hackerbot-Claw, targeted misconfigured GitHub Actions workflows across several high-profile repositories. The attack chain leveraged CI/CD misconfigurations—especially unsafe pull_request_target triggers—to achieve remote code execution (RCE) and steal privileged tokens.

What makes this incident important is not just the vulnerability class. We have known about CI misconfigurations for years. The real shift is that the exploitation process itself has been automated by an agent capable of scanning, exploiting, and validating compromises at scale.

This post breaks down how the attack worked, the vulnerabilities it abused, and what security teams should learn from it.

Why GitHub Actions Became a High-Value Target

GitHub Actions has become the default CI/CD engine for modern software projects. It automates:

  • builds
  • testing
  • release pipelines
  • dependency scanning
  • artifact publishing

Because CI workflows frequently require access to secrets, tokens, and repository permissions, they are effectively trusted execution environments inside the development lifecycle.

If an attacker gains code execution inside a CI runner, they may be able to:

  • access repository secrets
  • modify source code
  • publish malicious artifacts
  • push commits or delete releases
  • interact with external infrastructure

In other words, CI pipelines are part of the software supply chain attack surface.

The Hackerbot-Claw Campaign

The Hackerbot-Claw campaign began shortly after the creation of the attacker’s GitHub account in February 2026. Within days, it began systematically targeting open-source projects with vulnerable workflows.

Among the repositories targeted were:

  • microsoft/ai-discovery-agent
  • DataDog/datadog-iac-scanner
  • avelino/awesome-go
  • aquasecurity/trivy
  • project-akri/akri
  • RustPython/RustPython

Several of these projects experienced successful code execution inside CI pipelines, and in some cases token exfiltration allowed further repository manipulation.

The attacker employed multiple techniques—including branch name injection, filename injection, script injection, and prompt injection against AI-driven workflows.

The Core Vulnerability: pull_request_target

Many of the exploited workflows relied on a dangerous configuration pattern in GitHub Actions.

Example workflow:

name: Dangerous PR runneron:
  pull_request_target:jobs:
  run-pr-code:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}      - name: Run script
        run: |
          scripts/run.sh

This configuration introduces a critical problem:

  1. pull_request_target runs workflows in the context of the base repository, not the fork.
  2. The workflow often has write permissions via GITHUB_TOKEN.
  3. If the workflow checks out untrusted PR code, that code can execute with elevated privileges.

In other words, untrusted code is executed with trusted credentials.

This class of vulnerability is sometimes called a “pwn request.”

The Attack Chain

Although the bot used several exploitation techniques, the underlying attack pattern remained consistent.

1. Repository Reconnaissance

The bot continuously scanned public repositories for CI workflow files.

Targets were identified by patterns such as:

  • pull_request_target triggers
  • write-scoped GITHUB_TOKEN
  • unsafe variable interpolation
  • dynamic shell execution
  • missing authorization checks

This scanning phase was fully automated.

2. Crafting a Malicious Pull Request

Once a vulnerable workflow was found, the bot generated a pull request designed to trigger CI execution.

Techniques included:

  • branch name injection
  • filename injection
  • malicious code in PR content
  • trigger manipulation

The goal was to inject payloads that the CI runner would execute.

3. Triggering CI Execution

When the workflow ran, the malicious input was processed by the pipeline.

If the workflow:

  • checked out attacker-controlled code, or
  • interpolated user input into shell commands,

then the attacker gained arbitrary command execution inside the CI runner.

4. Token Exfiltration

Once inside the runner environment, the attacker attempted to extract credentials.

Typical targets included:

  • GITHUB_TOKEN
  • personal access tokens (PAT)
  • repository secrets

In at least one case, the attacker successfully exfiltrated a write-scoped token from a repository.

5. Repository Manipulation

With a privileged token, the attacker could interact with the GitHub API.

Possible actions included:

  • pushing commits
  • deleting releases
  • modifying repository metadata
  • publishing malicious artifacts

One scenario even involved publishing a malicious VS Code extension artifact.

What Makes This Attack Different

CI vulnerabilities themselves are not new. What is new is the automation layer.

Hackerbot-Claw was not a human attacker manually probing repositories.

Instead, the bot:

  • scanned repositories continuously
  • detected vulnerable workflows
  • generated exploitation PRs
  • validated execution results
  • repeated the cycle automatically

This effectively turned CI exploitation into a scalable autonomous attack pipeline.

The implication is clear:

When attackers automate exploitation, manual defense mechanisms become insufficient.

The Expanding Attack Surface: AI-Driven Workflows

One particularly interesting vector involved AI-based code review workflows.

Some repositories had automation where an LLM or agent reviewed pull requests. The attacker attempted prompt injection attacks against these systems to trick them into approving malicious changes.

This introduces a new class of supply-chain risk:

  • CI pipelines now include LLM agents
  • LLMs can process untrusted PR content
  • prompt injection can manipulate automation logic

As more development workflows integrate AI agents, the attack surface grows significantly.

Defensive Measures

Defending against CI pipeline exploitation requires tightening workflow security.

Key recommendations include:

Avoid pull_request_target for untrusted code

Prefer:

on:
  pull_request:

Instead of:

on:
  pull_request_target:

Restrict GITHUB_TOKEN permissions

Always use least privilege.

Example:

permissions:
  contents: read

Avoid granting write permissions unless strictly necessary.

Never run untrusted code with secrets

If PR code must run:

  • isolate it
  • disable secrets
  • run with read-only permissions

Validate workflow inputs

Avoid patterns like:

run: echo "${{ github.event.pull_request.title }}" | bash

User-controlled values should never be executed.

Implement CI security scanning

Automated tooling should check for:

  • unsafe workflow triggers
  • secret exposure
  • excessive token permissions
  • command injection patterns

The Bigger Picture

The Hackerbot-Claw campaign marks a turning point in supply-chain security.

Three trends are converging:

  1. CI pipelines hold powerful credentials
  2. AI agents are being integrated into development workflows
  3. Attackers are automating exploitation with autonomous bots

The result is a new security paradigm where machines are attacking machines inside the development pipeline.

Software supply chain security is no longer just about protecting code. It now requires protecting the automation systems that build, test, and release that code.

And as this incident shows, those systems are becoming the next major battlefield.

CyberDefender