An autonomous bot spent a week in February attacking CI/CD pipelines across seven major open-source repositories. It compromised projects with 140,000+ stars, stole credentials with write access to production, and used those tokens to delete releases and push malicious artifacts to a marketplace. Nobody noticed for days.

The bot, dubbed hackerbot-claw, wasn't brute-forcing passwords or scanning for open ports. It was opening pull requests. Carefully crafted pull requests that exploited how GitHub Actions workflows handle untrusted input. It used at least five distinct techniques across its targets, adapting its approach to each repository's specific CI/CD configuration.

This is what pipeline security threats look like now. They're automated, creative, and they target the same workflow configuration files that most engineering teams set up once and never review. If you're running a CI/CD pipeline in 2026, you're defending against automated adversaries that can probe your workflow configs faster than your team reviews them.

What Happened

The campaign ran February 21 through 28, 2026, targeting repositories including Aqua Security's Trivy (25K+ stars), awesome-go (140K+ stars), Microsoft's ai-discovery-agent, DataDog's IAC scanner, a CNCF project, and RustPython.

The attack chain was consistent: identify a vulnerable workflow, craft an input that achieves code execution inside the CI runner, exfiltrate the GITHUB_TOKEN or any available secrets, and escalate.

The most damaging hit was Trivy. The bot stole a Personal Access Token through a vulnerable pull_request_target workflow, then used it to privatize the repository, delete all GitHub releases, and push malicious artifacts to the project's VS Code extension on the Open VSX marketplace. One vulnerable workflow configuration led to a supply chain attack affecting downstream users.

The Patterns That Get Exploited

Every vulnerability the bot exploited maps to a configuration choice that felt reasonable when it was made.

Pull request target with untrusted checkout. The pull_request_target event runs workflows in the context of the base repository, with access to secrets. If that workflow checks out the PR's fork code and executes it, you've given an external contributor access to your secrets. This is how Trivy and awesome-go were compromised.

Unescaped expression injection. GitHub Actions' $ expressions get interpolated before bash execution. If a workflow writes echo $ without quotes, an attacker who controls that value controls your shell. Branch names, PR titles, filenames: all attacker-controlled inputs that end up in expressions. We see this in real codebases constantly.

Supply chain escalation via unpinned actions. Referencing a third-party action by @master or @v1 means you're trusting whatever code is at that tag when your workflow runs. If the action's repository is compromised, or if a maintainer pushes a bad update, your next build runs the attacker's code with whatever permissions your workflow grants. Actions that have write permissions and track a mutable reference are the highest-priority risk.

Securing Your Pipeline

The principles that would have prevented every hackerbot-claw attack are straightforward. The challenge is applying them consistently.

Scope permissions to the minimum. Every workflow, every agent, every automated tool should have exactly the permissions it needs. Default to contents: read and explicitly grant write access only where required.

Pin third-party actions to SHA hashes. Never reference actions by branch or mutable tag. Pin to the full commit SHA. Prioritize actions that run with write permissions. Dependabot can automate SHA pin updates when new versions are released.

Treat all PR-sourced input as untrusted. Branch names, PR titles, commit messages, filenames, issue comments: anything an external contributor controls should never be interpolated directly into shell commands. Use environment variables instead of $ expressions in run: blocks.

Audit pull_request_target workflows. If any workflow uses pull_request_target and checks out PR code, it's vulnerable. Either switch to pull_request (which doesn't have access to secrets) or ensure you never execute code from the PR branch.

Restrict AI agent permissions. If you're running AI coding assistants in CI/CD, restrict which tools they can invoke and add author_association checks to any workflow triggered by comments. Protect AI configuration files like CLAUDE.md and .cursorrules with CODEOWNERS so changes require security review.

Monitor CI runner behavior. The hackerbot-claw payloads all executed curl | bash. That pattern should trigger immediate alerts. Runtime monitoring catches attacks that static analysis of workflow configs misses.

The Takeaway

The hackerbot-claw campaign wasn't sophisticated. It exploited well-known workflow configuration mistakes that the security community has been warning about for years. What was new was the automation: an AI system methodically testing each repository's defenses and adapting its techniques.

The fix isn't a new tool. It's treating your CI/CD configuration with the same rigor you give your application code. Audit it, scope it, monitor it. And assume that something is already testing it.

If you want help running a full pipeline security review , including agentic threat modeling for your CI/CD workflows , we do this regularly for engineering teams. Let's talk through what you're seeing.

About IOmergent
IOmergent provides fractional CISO services and managed cloud security for growing organizations that need experienced security leadership without a full-time hire. We help companies build security programs, manage cloud risk, and meet compliance requirements.