GitHub Actions compromise exposes the CI token abuse problem

At a glance

What this is: HackerBot-Claw is an automated campaign that exploits misconfigured GitHub Actions workflows to steal privileged tokens and control repositories.

Why it matters: It matters to IAM practitioners because CI identities, secrets, and repository permissions now behave like high-value NHI assets, and weak workflow design can turn routine automation into privilege escalation.

By the numbers:

• In 2025, a supply chain attack against the tj-actions/changed-files action affected over 23,000 workflows.

👉 Read Orca Security's analysis of GitHub Actions token abuse and repository compromise

Context

GitHub Actions is a CI/CD execution layer that can run code, use tokens, and interact with repository resources. In this campaign, the problem is not the platform itself but the identity model around it: workflows that grant write-level access to untrusted pull request content create a token abuse path that traditional software supply chain controls do not fully contain.

For identity teams, the key issue is that CI pipelines often hold non-human identities with more privilege than they need and less oversight than human accounts. Once a workflow can execute untrusted input with elevated rights, the repository becomes an access boundary, not just a code boundary, and governance must treat it that way.

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. That lets an untrusted contribution inherit repository rights, secret access, or release permissions that should never be available during validation. The result is token leakage, unauthorized repository actions, or both, especially when pull_request_target is combined with broad permissions.

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. When those tokens are long-lived, over-scoped, or reused across workflows, they function like privileged NHIs with poor lifecycle governance. That is why identity teams should inventory them, scope them tightly, and review them like any other privileged machine credential.

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. If the same job can build, test, and deploy, the permission model is likely too coarse. Another indicator is repeated reliance on PATs instead of narrowly scoped, workflow-specific credentials.

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.

Technical breakdown

Misconfigured pull_request_target workflows as the entry point

The campaign starts by scanning public repositories for GitHub Actions workflows that use pull_request_target, excessive permissions, untrusted checkouts, or stored secrets. That combination is dangerous because the workflow executes in a privileged repository context while processing attacker-controlled input. In effect, the pipeline becomes a trust bridge between unreviewed code and elevated credentials. The issue is not code execution alone. The issue is that the workflow’s authorization model grants the job access it does not need in order to do its work, especially when the job can read or act on repository secrets.

Practical implication: separate untrusted pull request handling from privileged workflow execution and remove write access from jobs that process external input.

Privileged token leakage through CI execution

Once a vulnerable workflow is triggered, the attacker tries to force CI to reveal a GitHub token or run actions under a privileged token such as GITHUB_TOKEN or a stored PAT. If the workflow logs secrets, checks out attacker-controlled code, or passes token-bearing context into scripts, the token can be exposed or abused inside the job. This is a classic identity failure in CI: the execution environment inherits permissions that should have been isolated from untrusted content. The result is not merely a broken build, but an NHI compromise inside the software delivery path.

Practical implication: enforce strict token scoping, block secret access in untrusted jobs, and review every workflow step that can surface credentials.

Repository control after token abuse

With a stolen token, the attacker no longer needs to exploit the workflow itself. They can call GitHub APIs directly to delete releases, rename repositories, push commits, or publish malicious artifacts. This is where CI abuse turns into operational and supply chain impact. In identity terms, the compromised token acts like a standing privileged credential for the repository, and the damage is limited only by the token’s granted scope and the organisation’s detection speed. The real weakness is privilege concentration in automation identities that are rarely reviewed like human admin accounts.

Practical implication: inventory CI tokens as privileged NHIs, constrain repository-scoped rights, and monitor API actions that change releases, assets, or branch state.

Threat narrative

Attacker objective: The objective is to turn a misconfigured CI workflow into direct repository control and use that access to manipulate software delivery and downstream trust.

1. Entry occurs when the attacker identifies a public repository whose GitHub Actions workflow uses pull_request_target or another privileged pattern that can run attacker-controlled input.
2. Credential access happens when the workflow exposes or reuses a write-capable token, such as GITHUB_TOKEN or a PAT, inside the CI job.
3. Impact follows when the attacker uses the token for repository control, including release deletion, malicious artifact publication, and full repository takeover.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing privilege in CI is the failure mode this campaign exploits. The workflow assumes privileged access can safely exist long enough for a job to complete, but that assumption collapses when untrusted pull requests can trigger elevated execution. This is not simply overprivilege in the abstract. It is standing repository authority embedded in automation, and that is the exact control gap attackers are mining. The implication is that CI privilege must be designed as ephemeral and task-scoped, not persistent.

Privilege escalation in GitHub Actions often begins before the code ever runs. The harmful pattern is the authorization boundary around the workflow trigger, not only the script body. pull_request_target, reused secrets, and broad token scopes create a control plane where attacker influence reaches privileged actions without needing a classic exploit chain. The practical conclusion is that repository governance and workflow governance must be designed together.

Secret exposure in CI is a downstream symptom of weak identity boundaries. When tokens are available to jobs that process outside input, secret leakage is not an edge case but an expected outcome under pressure. The broader lesson for NHI governance is that code pipelines now behave like high-value identity infrastructure, so token lifecycle, review, and segregation matter as much here as they do for production service accounts.

CI compromise is increasingly a supply chain identity pattern, not a one-off incident. The attack method scales because the same misconfiguration can be reused across many repositories and many organisations. That means the category risk is repeatable privilege misuse through automation, not a single flawed project. Practitioners should read this as evidence that CI identities need the same governance discipline applied to other privileged NHIs.

From our research:

• 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.
• For a broader control lens, read 52 NHI Breaches Analysis for the recurring failure patterns behind identity-driven incidents.

What this signals

Secret sprawl in CI is now a governance signal, not just an operational nuisance. If workflows can access write-capable tokens while handling untrusted input, the environment is already beyond conventional least-privilege assumptions. Teams should expect more attacks that target repository automation as an identity layer, and they should align workflow governance with the same review discipline used for other privileged NHIs.

Workflow identities need lifecycle controls just as much as production service accounts do. A CI token that survives workflow changes, repository refactors, or project handoffs becomes liability, not utility. That is why offboarding, rotation, and access review must include build and release automation, not only servers and apps.

Standing privilege in automation creates identity blast radius. When a single workflow can build, sign, publish, or delete artifacts, the compromise of that workflow becomes a compromise of the release path. Use the NHI lifecycle lens to break that concentration before attackers do.

For practitioners

• Remove privileged execution from untrusted PR paths Keep pull_request_target workflows from running scripts or checks that can touch write-capable tokens. Use a separate low-privilege validation path for external contributions and reserve privileged actions for trusted, manually approved jobs.
• Scope every CI token to the minimum repository action Audit GITHUB_TOKEN permissions, stored PATs, and any reusable credentials in workflows. Remove write access where read-only behaviour is sufficient, and split build, test, and release duties so one job cannot perform all three.
• 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. Revoke or rotate credentials when workflows change, not only after a confirmed leak. See the Ultimate Guide to NHIs for the governance context and the 52 NHI Breaches Analysis for real failure patterns.
• Monitor repository-changing API activity Alert on release deletion, repository renaming, unusual artifact publication, and branch or settings changes from automation identities. These are the actions that convert token theft into operational impact and should be treated as containment signals.

Key takeaways

• GitHub Actions misconfigurations are an identity problem because they let untrusted code inherit repository privileges.
• The scale of CI abuse is material, with more than 23,000 workflows affected in one 2025 supply-chain incident.
• The control that changes the outcome is tight token scoping, separated trust boundaries, and governance for automation identities.

Key terms

• GitHub Actions Workflow Identity: The automation identity a workflow uses to authenticate and act inside a repository or connected service. It is a non-human identity because it can create, modify, or delete resources without a person directly operating each action. Governance depends on scope, trigger design, and secret handling.
• Pull Request Target Risk: A workflow risk pattern where untrusted pull request content is processed in a privileged context. Because the job may run with write access or access to secrets, the boundary between review and execution collapses. The control failure is not the pull request itself, but the permissions attached to the trigger.
• CI Privilege Escalation: A condition where an automation job obtains more repository or platform authority than its declared function requires. In practice, this often comes from broad token scopes, reused secrets, or unsafe workflow triggers. The result is that build and test infrastructure can be turned into a control plane for attack.

Deepen your knowledge

GitHub Actions token abuse and CI privilege governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring automation identities under the same discipline as other privileged accounts, it is worth exploring.

This post draws on content published by Orca Security: HackerBot-Claw and the abuse of misconfigured GitHub Actions workflows. Read the original.