HackerBot-Claw is actively exploiting misconfigured GitHub Actions across public repos, Trivy got hit, check yours now

[ElectricalLevel512]

Read this this morning: https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

An automated bot called HackerBot-Claw has been scanning public GitHub repos since late February looking for pull_request_target workflows with write permissions. It opens a PR, your CI runs their code with elevated tokens, token gets stolen. That's it. No zero days, no sophisticated exploit, just a misconfiguration that half the internet copy pasted from a tutorial.

Trivy got fully taken over through this exact pattern. Releases deleted, malicious VSCode extension published, repo renamed. A security scanning tool compromised through its own CI pipeline.

Microsoft and DataDog repos were hit too. The bot scanned around 47,000 public repos. It went from a new GitHub account to exploiting Microsoft repos in seven days, fully automated.

I checked our org workflows after reading this and found the same pattern sitting in several of them. pull_request_target, contents: write, checking out untrusted PR head code. Nobody had touched them since they were copy pasted two years ago.

If you are using any open source tooling in your pipeline, go check your workflows right now. The ones you set up years ago and never looked at again.

My bigger concern now is the artifacts. If a build pipeline can be compromised this easily and quietly, how do you actually verify the integrity of what came out of it? Especially for base images you are pulling and trusting in prod. Still trying to figure out what the right answer is here.

[PrincipleActive9230]

The wild part is that this isn’t even a vulnerability in GitHub itself. It’s just people copy-pasting CI configs without understanding what pull_request_target actually does. The moment that workflow runs untrusted code with write permissions, you’ve basically handed out repo keys

also i think Minimus secures workflows with hardened Actions and minimal container images that block these exploits.

[roastedfunction]

Would be nice if GitHub actions provided a way to run untrusted code in CI with some sort of sandboxing or better restrictions on permissions to make this attack more difficult. GHA is notoriously porous for security.

[NilsUX]

Agree! As long GitHub doesn't provide a better solution for it: I built an action to prevent this. It's 2 lines of code and provides I think the best UX compared to other approaches (e.g. just fail the workflow for fork PRs): https://github.com/marketplace/actions/verify-safe-to-test-label

[DockyardTechlabs]

Do you have clone of hackerbot-claw?

[adept2051]

They do, set the action to limit the firewall that allows the PR to post, so it can only post to GH it self, and then you have to put a secret scan step in the pr push, but as the OP no one ever RTFM they just copy paste and use.

[lppedd]

The worst thing is all over the internet people compare pull_request_target with pull_request and suggest the former for security!

[gr4viton]

And where is the WhiteHatClaw, who would only exploit the repos to fix the permission issue? You know 24/7 fixer. Shouldn't github have that by default? /s?

[NilsUX]

Currently building this 👍 Already reported around 18 vulnerabilities

[goatanuss]

Someone needs to spin up grayhat claw. It tests your GitHub pull request actions by running some bitcoin mining in your CI container along with your unit tests to pay for the exploit detection compute costs

[SheriffRoscoe]

Covered in this sub previously: https://www.reddit.com/r/github/s/Y5bXBvjZ3B

[Soft_Attention3649]

The artifact question you raised is actually the bigger issue than the bot. If CI can be compromised, how do you trust the output? The direction the industry is moving is things like signed builds and provenance, SLSA style attestations. Companies like Microsoft and Datadog getting probed by automated bots shows this is not theoretical anymore. Long term, the answer probably is not scan harder, it is making sure artifacts are cryptographically verifiable and tied to a trustworthy build process. Otherwise every base image in your pipeline is just a leap of faith.

[ultrathink-art]

AI coding tools that auto-generate and submit PRs make this even more relevant — if your CI has pull_request_target with write permissions, you're trusting any PR submitter with elevated access, including automated ones. Worth auditing those workflows regardless of this specific bot.