Topic starter
10/06/2026 11:32 pm
TL;DR: HackerBot-Claw systematically scans public GitHub repositories for misconfigured Actions workflows, then uses elevated pull_request_target execution to steal privileged tokens and take repository actions, according to Orca Security. The pattern shows that CI/CD automation can turn trust boundaries into control-plane abuse paths when token scope and untrusted code execution are not tightly separated.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “HackerBot-Claw: An AI-Assisted Campaign Targeting GitHub Actions Pipelines”.
By the numbers:
- A 2025 supply chain attack against tj-actions/changed-files affected more than 23,000 workflows.
Key questions
Q: What breaks when GitHub Actions workflows run untrusted pull requests with write access?
A: The workflow boundary breaks because attacker-controlled input can execute in a privileged context.
Q: Why do misconfigured CI workflows create such a large attack surface?
A: Because CI systems now hold the tokens that can commit code, manage releases, and touch security artifacts.
Q: How should security teams reduce risk from compromised GitHub Actions workflows?
A: Security teams should treat workflows as privileged non-human identities.
Practitioner guidance
- Restrict pull_request_target to trusted operations only Keep untrusted code paths away from write-capable workflow jobs.
- Minimise workflow token permissions Review GITHUB_TOKEN and PAT scopes job by job, then remove commit, release, and advisory permissions unless a step truly needs them.
- Inspect workflows for untrusted checkout patterns Look for jobs that check out pull request head commits and then run shell scripts or composite actions with elevated rights.
Bottom line: GitHub Actions workflows can become privileged identity paths when pull requests are allowed to influence jobs that still hold write access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 24 hours ago by NHI Mgmt Group
12/06/2026 5:40 am
GitHub Actions token abuse is an identity governance problem, not just a CI misconfiguration. Workflow tokens behave like non-human identities because they authenticate automation and can carry durable authority across repository actions. When those tokens are granted beyond the job’s true trust boundary, the pipeline becomes a governed identity surface. The practitioner conclusion is that CI access has to be reviewed as access, not merely as build configuration.
A question worth separating out:
Q: How should teams respond when CI or developer secrets are exposed?
A: Teams should identify the affected identities, revoke or rotate exposed credentials, review ownership and scope, and verify whether the compromised material reached any production-adjacent systems. The operational challenge is to close exposure quickly without breaking dependent services.
👉 Read our full editorial: GitHub Actions compromise exposes the CI token abuse problem
This post was modified 24 hours ago by NHI Mgmt Group