GitHub Actions compromise exposes the CI token abuse problem

At a glance

What this is: This is an analysis of how misconfigured GitHub Actions workflows let attackers abuse CI tokens to gain repository control and leak credentials.

Why it matters: It matters because CI/CD has become an identity surface, and IAM teams need to treat workflow tokens, permissions, and untrusted execution as governed access paths rather than build plumbing.

By the numbers:

• A 2025 supply chain attack against tj-actions/changed-files affected more than 23,000 workflows.

Context

GitHub Actions is a CI/CD system that runs code in response to repository events, which means its tokens and permissions can act like identities with real authority. When pull request workflows are allowed to run untrusted code with write access, the pipeline stops being a build helper and becomes an access path.

This article centres on a governance failure in non-human identity handling: workflow credentials were usable beyond the scope their owners likely intended, and untrusted input could reach privileged execution. The result is not just a software supply chain issue, but an identity boundary problem inside development automation.

Orca Security describes HackerBot-Claw as an automated campaign that searched public repositories for these conditions and turned them into token theft and repository abuse. The starting position here is common, not exceptional, which is why the issue deserves governance treatment rather than incident-by-incident cleanup.

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 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. When those credentials are attached to automated jobs that process public input, a single workflow mistake can expose both authentication material and operational authority. The risk is structural, not just procedural.

Q: How should security teams reduce risk from compromised GitHub Actions workflows?

A: Security teams should treat workflows as privileged non-human identities. The practical fix is to inventory every secret and role a workflow can reach, shorten credential lifetimes, pin external actions to commit hashes, and monitor runtime behaviour for anomalies. If the workflow can deploy, read secrets, or call cloud APIs, it needs identity-level controls, not just code review.

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.

Technical breakdown

Why pull_request_target creates privileged execution risk

The pull_request_target trigger runs in the context of the base repository, not the attacker-controlled fork, so its token and secrets can inherit write-level authority. That makes it dangerous when the workflow checks out or executes code from the pull request itself, because untrusted content can then influence a privileged runner. The core mechanism is identity transitivity: execution context, token scope, and code origin are not kept separate. In practice, the workflow becomes a bridge from untrusted input to authenticated repository action.

Practical implication: treat pull_request_target workflows as privileged entry points and remove write permissions unless the workflow is explicitly designed for trusted operations.

How CI tokens become repository control planes

A CI token is not just a secret value. In GitHub Actions, GITHUB_TOKEN or a stored PAT can authorize commits, release changes, advisory updates, and other repository API actions. If that token is exposed during a job, the attacker does not need to break the platform itself; they can use the legitimate API surface that the workflow already trusted. This is why token scope and job design matter together. A narrow permission model can limit damage, but only if the workflow never hands privileged identity to untrusted steps.

Practical implication: map every workflow token to the repository actions it can perform and remove any permission not required by the job.

Why workflow scanning and untrusted checkout are the real attack combination

HackerBot-Claw appears to automate discovery of vulnerable workflow patterns such as elevated permissions, untrusted checkouts, and reused secrets. The attack succeeds because the workflow combines two conditions: it is reachable from public input and it executes with rights that outlast that input. That combination creates a control failure in CI governance, not a code vulnerability in the usual sense. The problem is architectural. Once a job can both consume attacker-controlled content and act as a privileged identity, the repository becomes reachable through automation.

Practical implication: review workflow reachability and code provenance together, not as separate controls.

Threat narrative

Attacker objective: The attacker aims to turn a trusted CI workflow into repository control, enabling token theft, unauthorized changes, and downstream supply chain disruption.

1. Entry begins when the attacker identifies public repositories with vulnerable GitHub Actions workflows, especially those using pull_request_target and elevated permissions.
2. Credential access occurs when the workflow exposes a privileged token or PAT during execution, allowing the attacker to capture authentication material or use it directly.
3. Escalation follows as the stolen token is used for repository API actions such as release deletion, commit pushes, advisory creation, or repository manipulation.
4. Impact lands in full repository takeover or disruption of downstream distribution channels, turning CI compromise into software supply chain abuse.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing trust in untrusted pull request execution is the broken assumption this campaign exploits. The model assumes a workflow can accept external input while preserving repository control, but that assumption fails when the same job can execute attacker-controlled code and write back to the repository. The implication is that workflow trust boundaries must be treated as explicit governance objects, because the attack succeeds where execution context and authority are blended.

Token scope is now a blast-radius variable for development platforms. Once a workflow token can push commits, delete releases, or create advisories, the impact is no longer limited to one job run. This makes least privilege operationally relevant in CI/CD, not just in classic IAM. The practitioner conclusion is that token authority should be bounded to the smallest recoverable failure domain.

Ephemeral code, persistent authority: The campaign shows that transient pull request content can acquire durable control if workflow permissions are not strictly separated from execution provenance. That is a governance gap because the identity attached to the runner can outlive the trustworthiness of the code it processes. The implication is that CI programmes must distinguish between the lifespan of the input and the lifespan of the authority.

Supply chain compromise is now often an identity reuse story. The article’s broader context, including the tj-actions incident, shows that one poisoned component or workflow can spread credential exposure across many repositories. This links CI security to NHI governance because reused automation identities can amplify a single mistake into ecosystem-wide exposure. The practitioner conclusion is that shared automation identities deserve lifecycle control equal to other privileged accounts.

What this signals

Ephemeral code, persistent authority: GitHub Actions shows why development pipelines need identity governance, not just build monitoring. If a job can ingest public input and still act with write privileges, the review model has already lost the most important decision point: who is allowed to act on whose behalf.

CI credentials are now part of the enterprise identity estate. The practical boundary is no longer between humans and systems, but between trusted and untrusted execution contexts. For practitioners, that means workflow permissions, token lifecycle, and repository provenance need the same scrutiny applied to other privileged access paths.

For practitioners

• Restrict pull_request_target to trusted operations only Keep untrusted code paths away from write-capable workflow jobs. Use separate workflows for validation and repository-changing actions so external contributions cannot inherit privileged execution.
• 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. Default to read-only behaviour for public pull request runs.
• 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. Those combinations should be treated as high-risk execution paths.
• Rotate credentials after workflow abuse is suspected If a workflow exposed a PAT or other secret, revoke the token, rotate related credentials, and verify that downstream automation no longer depends on the compromised identity.
• Map CI identities to repository actions Document which automation identities can push code, delete releases, create advisories, or publish artifacts, then align those powers to the minimum necessary repository role.

Key takeaways

• GitHub Actions workflows can become privileged identity paths when pull requests are allowed to influence jobs that still hold write access.
• The article links misconfigured CI to token theft, repository control, and downstream supply chain disruption, not just a single exposed secret.
• The control failure is separation of duties inside automation: untrusted code, privileged tokens, and repository-changing actions must not live in the same workflow path.

Key terms

• Pull Request Trigger Privilege: The permission a workflow inherits when it runs in response to a pull request. In GitHub Actions, this matters because the same trigger can either validate code safely or execute with repository authority, depending on how token scope and checkout behaviour are configured.
• Session Token Exposure: Session token exposure occurs when authentication tokens or session artifacts are stored, transmitted, or logged in places they should not be. Once exposed, they can function like reusable credentials. This makes them part of identity and access risk, not only application behaviour.
• Untrusted Checkout: A workflow pattern where code from a pull request or external source is checked out into the runner and then executed. This is a major supply chain risk because the workflow may inherit repository secrets or permissions while running attacker-controlled logic.
• CI Identity Boundary: The line between trusted automation and untrusted input inside a build or test pipeline. When that boundary is weak, CI identities can be abused like any other privileged account, especially in systems that process public contributions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.