> ## Content Index
> Fetch the complete content index at: https://www.sredevops.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# High severity Github Actions exploit: hackerbot-claw uses your ci/cd as a "pwn-as-a-service" platform
- URL: https://www.sredevops.org/en/high-severity-github-actions-exploit-hackerbot-claw-uses-your-ci-cd-as-a-pwn-as-a-service-platform/
- Published: 2026-03-04T02:48:44.000Z
- Updated: 2026-03-04T02:48:44.000Z
- Author: Nicolás Georger
- Tags: Security, Pipelines, News, Github, DevSecOps, CI-CD, English

## 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.

```yaml
# 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.

```yaml
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.

```bash
# 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.

```yaml
- 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](https://best.openssf.org/SCM-BestPractices/?ref=sredevops.org). 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](https://docs.github.com/en/actions/concepts/security/script-injections?ref=sredevops.org)
- [OpenSSF: Mitigating attack vectors in GitHub workflows](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows?ref=sredevops.org)
- [Wiz.io: GitHub Actions security guide](https://www.wiz.io/blog/github-actions-security-guide?ref=sredevops.org)
- [OpenSSF SCM best practices](https://best.openssf.org/SCM-BestPractices/?ref=sredevops.org)

---

**Source:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect at OpenSSF / The Linux Foundation.  
[GitHub](https://github.com/SecurityCRob?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/darthcrob?ref=sredevops.org)