hackerbot-claw Operation Review: Pull Requests as an Attack Vector in GitHub Actions

Executive Summary

In February 2026, an autonomous bot named hackerbot-claw exploited insecure GitHub Actions configurations across multiple high-profile repositories. The campaign abused unsafe pull_request_target triggers, unsanitized inputs, dynamic shell execution, and overprivileged GITHUB_TOKEN permissions to achieve remote code execution (RCE) in GitHub-hosted runners.

Across at least six repositories, the bot successfully executed arbitrary commands, and in some cases exfiltrated privileged GitHub tokens with write permissions. The attacks demonstrated how CI/CD pipelines, often treated as auxiliary tooling, can become high-value execution environments capable of exposing secrets, modifying codebases, and potentially enabling broader supply chain compromise.

This campaign marks a shift toward agent-on-agent warfare, where a bot manipulated AI code reviewers to bypass security. Likely the work of a pentester testing ecosystem resilience rather than a malicious APT, it nonetheless highlights a critical reality: manual oversight is no longer an effective defense against autonomous, continuous CI/CD exploitation, longer an effective defense against autonomous, continuous CI/CD exploitation.

Why the hackerbot-claw Campaign Is Different

At first glance, this appears to be another CI misconfiguration incident. It is not.

This was a fully autonomous exploitation engine, not a manual intrusion.

The bot:

• Scanned public repositories continuously
• Identified exploitable GitHub Actions patterns
• Generated malicious pull requests
• Triggered workflows
• Tested execution paths
• Logged successful compromises automatically

No human operator was required for each attack cycle.

No Zero-Days Were Used

Every successful compromise stemmed from insecure workflow design:

• Overly permissive pull_request_target
• Unsanitized branch names and filenames
• Direct interpolation of ${{ }} expressions inside run: blocks
• Dynamic shell evaluation without escaping
• Over-privileged GITHUB_TOKEN permissions

The boundary failed due to configuration assumptions, not software flaws.

Why GitHub Actions Runners Are High-Value Targets

GitHub-hosted runners are ephemeral but privileged.

During execution, they often have:

• contents: write repository permissions
• Access to secrets
• Artifact publishing capabilities
• Container registry credentials
• Cloud deployment tokens

RCE inside a CI runner is not “just shell access.” It is execution inside a trusted automation pipeline capable of:

• Modifying source code
• Tampering with releases
• Injecting supply chain backdoors
• Pivoting into cloud infrastructure

CI/CD is now a primary attack surface.

How the hackerbot-claw Attack Works

Despite using five techniques, every compromise followed the same playbook.

1. Reconnaissance

The bot scanned public repositories for:

• pull_request_target workflows that check out fork code
• issue_comment triggers without authorization checks
• ${{ }} expressions interpolated into shell commands
• Overly broad GITHUB_TOKEN permissions

2. Trigger Creation

The bot opened a benign-looking pull request.

The malicious payload was embedded in:

• A Go init() function
• A branch name
• A filename
• A modified script
• An AI prompt file

3. Code Execution

The vulnerable workflow:

• Checked out attacker-controlled code
• Executed it with repository permissions
• Exposed secrets and tokens

Because pull_request_target runs in the context of the target repository, it executes with trusted privileges.

4. Second-Stage Payload

All attacks called back to:

hackmoltrepeat.com/molt

This delivered a second-stage script.

5. Credential Exfiltration

In confirmed cases, the bot exfiltrated:

• GITHUB_TOKEN
• Personal Access Tokens (PATs)

Exfiltration endpoint:
recv.hackmoltrepeat.com

Stolen tokens were used to:

• Push commits
• Delete releases
• Modify repositories
• Alter workflows

Tracking It All: The Activity Log

The bot even maintained a live scoreboard of its attacks. A GitHub Actions workflow in the bot’s own profile, fetching an activity log from a private Gist and injecting it into the bot’s public README between HTML comment markers. This is how the bot’s profile displayed a “Recent Activity” section showing 5 successful exploitation sessions – it was automatically updated after each attack run. In other words, the bot wasn’t just attacking, it was logging its kills and publishing them for anyone to see.

Deep Dive: awesome-go Token Theft via Go init() Injection

Of all 7 attacks in the hackerbot-claw campaign, the one targeting avelino/awesome-go was the most damaging – and the most instructive. It demonstrates exactly how a seemingly minor workflow misconfiguration can lead to full repository compromise.

awesome-go is one of the most popular repositories on GitHub with over 140,000 stars. It’s a curated list of Go packages maintained by the community. The repository had a workflow called PR Quality Checks (pr-quality-check.yaml) that ran automatically on every pull request to validate submissions.

The workflow did something that many repositories do: it checked out the pull request’s code and ran a script against it. The problem was how it was triggered and what code it checked out.

The Vulnerability

The workflow:

• Used pull_request_target
• Checked out fork code using:

ref: ${{ github.event.pull_request.head.sha }}

This is the classic Pwn Request pattern.

The workflow ran with target repository permissions but executed attacker-controlled code.

The Exploit

The attacker modified a Go script to include:

This does two things:

1. Exfiltrates the GITHUB_TOKEN – sends it via HTTP POST to recv.hackmoltrepeat.com, along with the repository name
2. Downloads and executes a second-stage payload – fetches a script from hackmoltrepeat.com/molt and pipes it to bash

Impact

With a write-scoped token, an attacker can:

• Push directly to main
• Modify GitHub Actions workflows
• Merge malicious pull requests
• Persist access
• Disrupt releases

Risk Level: Critical

Confirmed Techniques Used Across Repositories

AI Prompt Injection as an Emerging CI Attack Vector

One attack modified a CLAUDE.md file used by an AI reviewer.

This represents a new class of vulnerability:

• AI agents consuming untrusted context
• Tool-enabled automation with write access
• Prompt injection leading to unintended execution

As CI/CD pipelines integrate AI review tools, the trust boundary expands.

Configuration becomes executable logic.

Mitigation: How to Secure GitHub Actions Workflows

1. Avoid Executing Fork Code in pull_request_target

Never check out fork code inside pull_request_target.

If you must use it:

• Only check out github.sha
• Never execute PR head code
• Avoid secret access entirely

Prefer pull_request for untrusted code.

2. Sanitize All User Inputs

Treat these as attacker-controlled:

• Branch names
• Filenames
• Commit messages
• PR titles

Never interpolate ${{ }} directly inside run: blocks.

Use environment variables instead.

3. Enforce Least-Privilege GITHUB_TOKEN

Do not grant contents: write unless required.

A lint job does not need write access.

If awesome-go had used:

permissions:
contents: read

The exfiltrated token would have been useless.

4. Gate Comment-Triggered Workflows

For issue_comment triggers:

• Validate author_association
• Restrict to maintainers
• Avoid public execution triggers

5. Secure AI Integrations

If using AI agents:

• Restrict tool permissions
• Do not allow wildcard write access
• Do not ingest untrusted PR content as trusted context
• Follow vendor hardening guidance exactly

6. Monitor CI Behavior

Watch for:

• Unexpected outbound network traffic
• Long-running steps
• Workflow triggers from unknown accounts
• Base64-encoded shell payloads

CI logs should feed into centralized detection systems.

What This Means for Supply Chain Security

The hackerbot-claw campaign confirms:

• CI/CD pipelines are primary targets
• Automation is the new execution layer
• Manual review cannot detect all injection vectors
• Autonomous attackers can operate continuously

This was likely a pentesting experiment, not an APT campaign.

But the vulnerabilities remain widespread.

Conclusion

As of today, the hackerbot-claw GitHub account has been suspended and its repository is no longer accessible. But the damage is done – and more importantly, the vulnerabilities it exploited are still out there.

The bot scanned for well-documented misconfigurations in GitHub Actions workflows, and found them in repositories maintained by Microsoft, DataDog, Aqua Security, and the CNCF. 

CI/CD pipelines are no longer a secondary attack surface – they are a primary target. And defending against automated, AI-driven attackers requires automated defenses. Manual code review alone won’t catch a payload hidden in a branch name or a base64-encoded command embedded in a filename.

The question isn’t whether your workflows have these patterns. It’s whether you’ve checked.