Notifications
Clear all
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.
NHIMG editorial — based on content published by Orca Security: HackerBot-Claw and the abuse of misconfigured GitHub Actions workflows
By the numbers:
- In 2025, a supply chain attack against the tj-actions/changed-files action affected over 23,000 workflows.
Questions worth separating out
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 CI tokens behave like privileged non-human identities?
A: CI tokens can authenticate automated jobs, call APIs, and change repository state without human interaction.
Q: How do organisations know if GitHub Actions permissions are too broad?
A: A practical sign is when a workflow can read secrets, write to the repository, or publish releases while processing untrusted input.
Practitioner guidance
- Remove privileged execution from untrusted PR paths Keep pull_request_target workflows from running scripts or checks that can touch write-capable tokens.
- Scope every CI token to the minimum repository action Audit GITHUB_TOKEN permissions, stored PATs, and any reusable credentials in workflows.
- Treat CI credentials as privileged NHIs Inventory workflow secrets, map where they are exposed, and review them on the same cadence used for other non-human identities.
What's in the full article
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of vulnerable GitHub Actions workflow patterns, including pull_request_target and privileged checkouts.
- Repository-specific impact details showing how tokens were used for release deletion, commit pushes, and repository takeover.
- Mitigation guidance that maps directly to workflow hardening, token scoping, and safer handling of untrusted pull requests.
- Examples of impacted projects and the exploitation patterns associated with each target.
👉 Read Orca Security's analysis of GitHub Actions token abuse and repository compromise →
GitHub Actions token abuse: are your CI controls keeping up?
Explore further
12/06/2026 5:40 am
GitHub Actions security is now an identity governance problem, not just a pipeline hygiene problem. The campaign succeeds because workflow permissions, secrets, and repository actions were treated as implementation details rather than governed identities. Once a CI job can act with write privileges on untrusted input, the access model is already broken. Practitioners need to treat every automation token as a governed non-human identity with defined scope and review.
A few things that frame the scale:
- In 2025, a supply chain attack against the tj-actions/changed-files action affected over 23,000 workflows, according to Ultimate Guide to NHIs.
- 70% of organisations have not fully addressed NHI risk. That gap is especially visible when CI identities are left outside normal governance routines.
A question worth separating out:
Q: Who is accountable when a misconfigured workflow exposes repository credentials?
A: Accountability usually spans the platform engineering team, repository owners, and security governance because the failure sits at the intersection of code, identity, and policy. In regulated environments, the organisation must show that automation tokens were scoped, reviewed, and revoked according to policy. Governance frameworks such as NIST CSF and Zero Trust make that accountability explicit.
👉 Read our full editorial: GitHub Actions compromise exposes the CI token abuse problem
