overview

It turns out that automating your workflows also makes it incredibly easy for attackers to automate your demise. An autonomous attack campaign, tracked as "hackerbot-claw," is currently prowling public repositories. Its mission? Finding insecure GitHub Actions workflows and turning them into gateways for arbitrary code execution and credential exfiltration.

The campaign isn't just a script-kiddie's weekend project; it has successfully compromised several high-profile open-source projects. By abusing common misconfigurations, the bot effectively turns your CI/CD pipeline against you. If you’ve been treating your pull_request_target triggers with the reckless abandon of a developer on their fifth espresso, it’s time to pay attention.

The Linux Foundation and the OpenSSF are actively triaging the fallout, but the bot works faster than a committee.

anatomy of the attack

The "hackerbot-claw" bot isn't reinventing the wheel; it’s just using the wheel to run you over. It specifically targets workflows that:

• Use privileged triggers like pull_request_target.
• Execute untrusted code from forked pull requests without isolation.
• Include inline shell scripts that blindly trust user-controlled inputs.
• Lack any form of authorization check before firing off expensive (and dangerous) runners.

observed attack patterns

1. Direct script injection: Attackers modify a script within a PR. If the workflow executes that script with repository privileges, the attacker effectively owns the runner.
2. "Pwn request" (pull_request_target abuse): This trigger is the "God Mode" of GitHub Actions. When used to check out and run code from a fork, it grants that untrusted code access to secrets and a GITHUB_TOKEN with write permissions.
3. Context injection: Malicious payloads are hidden in branch names, PR titles, or file paths. If your workflow does something like echo "Checking out ${{ github.head_ref }}", you might find yourself executing echo "Checking out "; rm -rf / #.

a real-world casualty: project-akri/akri

In a documented case involving project-akri/akri, a malicious PR introduced a shell-injection payload into a script. Because the workflow lacked safeguards, it dutifully executed the attacker's commands, proving once again that computers will do exactly what you tell them to do, even if it's professional suicide.

recommended mitigations

If you don't want your repository to become a miner for someone else's cryptocurrency or a pivot point for a supply chain attack, implement these controls immediately.

1. harden your workflows

Stop using pull_request_target unless you absolutely have to. If you must use it, never check out the untrusted code from the PR head.

# BAD: This gives the fork's code access to your secrets
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }} # DANGER

2. enforce least privilege

Limit the GITHUB_TOKEN permissions at the top of your workflow file. If a job only needs to read the code, tell it so.

permissions:
  contents: read
  pull-requests: read

3. sanitize inputs like your life depends on it

Never interpolate GitHub context variables directly into shell scripts. Use environment variables instead.

# BAD: Vulnerable to injection
run: echo "Processing branch: ${{ github.head_ref }}"

# GOOD: Handled as data, not code
run: echo "Processing branch: $BRANCH_NAME"
env:
  BRANCH_NAME: ${{ github.head_ref }}

4. pin your actions

Don't trust tags like @v1. Tags can be moved. Use the full length commit SHA to ensure the code you're running is the code you reviewed.

- uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0

alignment with the openssf osps baseline

The ongoing "hackerbot-claw" campaign targets the exact gaps addressed by the OpenSSF OSPS (Open Source Project Security) Baseline. Projects that follow these guidelines are significantly harder to compromise.

• Least Privilege: Restrict GITHUB_TOKEN and use OIDC for short-lived cloud credentials.
• Protected CI/CD: Require maintainer approval for all first-time contributors before workflows run.
• Peer Review: Use CODEOWNERS to mandate that any change to .github/workflows/ is reviewed by a security-conscious human, not just a tired maintainer.

further reading & resources

• GitHub's official guidance on script injection
• OpenSSF: Mitigating attack vectors in GitHub workflows
• Wiz.io: GitHub Actions security guide
• OpenSSF SCM best practices

Source: Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect at OpenSSF / The Linux Foundation.
GitHub | LinkedIn