GitHub Actions command injection exposes supply chain credentials

At a glance

What this is: Sonar identifies how GitHub Actions command injection emerges when pull_request_target workflows interpolate untrusted input into runner commands or execute untrusted code with elevated permissions.

Why it matters: This matters because CI/CD workflows can turn a single unsafe input path into secrets theft, repository tampering, and downstream supply chain compromise.

Context

GitHub Actions is a workflow automation layer, but its security depends on where the job runs, what it can access, and whether untrusted input is safely handled. When a workflow triggered by pull_request_target can reach write-scoped tokens or repository secrets, the control problem shifts from build automation to privilege boundary enforcement.

The article sits at the intersection of application security, CI/CD governance, and identity. In practice, the risky asset is not just the workflow syntax but the token, secret, or checkout context that gives the workflow authority to act on behalf of the repository. That makes workflow trust, permission scope, and input sanitisation part of the same governance decision.

This is a common failure mode in modern software delivery: teams treat developer convenience as a proxy for trust. The article shows that assumption is atypical only when environments enforce strict token scoping and never let untrusted pull request content influence shell execution or third-party action behaviour.

Key questions

Q: What breaks when pull_request_target workflows process untrusted input?

A: The workflow can turn attacker-controlled text or branch names into executable shell syntax while still running with the base repository's permissions. That creates a path from harmless-looking metadata to secret exposure, release tampering, or package publication. The failure is not the trigger alone. It is the combination of privileged context, unsafe interpolation, and insufficient separation between review and execution.

Q: Why do CI/CD workflows with standing write permissions increase supply chain risk?

A: Standing write permissions widen the blast radius of a workflow compromise. If an attacker reaches code execution, a token with contents write or pull requests write can push commits, alter build logic, or merge malicious changes. Least privilege reduces that impact, and short-lived, narrowly scoped credentials are safer than persistent elevated access.

Q: What are the signs that a GitHub Actions workflow is misconfigured for public repository security?

A: Common warning signs include workflows that run automatically on forked pull requests, use pull_request_target while checking out untrusted code, echo untrusted input inside inline scripts, or rely on elevated GITHUB_TOKEN permissions. Another red flag is using social triggers such as issue comments to launch jobs that fetch or execute pull request content. These patterns create unnecessary exposure in public repositories.

Q: How should teams respond when they find suspicious GitHub Actions activity?

A: Contain the workflow first by freezing the affected branch, revoking exposed tokens, and reviewing recent job executions for encoded commands or unusual outbound connections. Then trace where the credentials could have been used, because the true risk is not just the modified workflow but the access it may have unlocked.

Technical breakdown

Why pull_request_target changes the trust boundary

GitHub Actions workflows are defined as YAML jobs and steps, but the security boundary is set by the trigger context. pull_request_target runs in the base repository context, which can expose write-capable GITHUB_TOKEN permissions and secrets that are not appropriate for untrusted contributor input. That means fields such as issue titles, branch names, and pull request metadata must be treated as hostile data, not as workflow parameters. The core mechanism is simple: if shell or action inputs are assembled from untrusted context without quoting or sanitisation, the runner executes attacker-controlled instructions.

Practical implication: Treat trigger choice as an authorisation decision, not just a pipeline event setting.

How command injection appears inside workflow steps

Command injection in CI/CD often happens when user-controlled values are interpolated directly into a run step. In shell, quoting and environment-variable handling matter because the shell decides whether text is data or executable syntax. GitHub’s recommended pattern is to place untrusted content into an environment variable and reference it safely, rather than inserting context expressions straight into the command line. The pitfall the article highlights is that GitHub Actions expression syntax can substitute values before the shell sees them, which defeats the protection users think they are getting from shell variables.

Practical implication: Review every run step for context expressions that bypass shell-safe variable handling.

Why checkout plus execute becomes code execution

A more dangerous pattern appears when a workflow checks out code from an untrusted pull request branch and then runs a third-party action or build command against that code. In that setup, the workflow is not merely processing input, it is executing attacker-supplied source in a privileged environment. The article’s example shows how a pull_request_target trigger, an explicit checkout of the head repository, and a command like cargo run can combine into full code execution. This is especially risky when the action being invoked obscures what it does internally, because the real execution path is hidden behind a trusted-looking abstraction.

Practical implication: Separate untrusted code review from privileged automation that can publish, deploy, or sign artefacts.

Threat narrative

Attacker objective: The attacker aims to turn a trusted CI/CD workflow into a credential-stealing and release-poisoning channel.

1. Entry occurs when an attacker supplies malicious pull request metadata, branch names, or repository content to a workflow that trusts unvalidated input.
2. Credential access follows when the workflow executes attacker-controlled commands or code in a context that can read secrets or use write-scoped tokens.
3. Escalation happens when the compromised workflow modifies the repository, publishes malicious artefacts, or leverages the token to reach downstream systems.
4. Impact is supply chain compromise, including secret theft, poisoned releases, and malware propagation to consumers and developers.

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.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

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

CI/CD trust boundary drift is the real governance issue: the problem is not simply malformed YAML, but automation running with privileges that no longer match the trust level of the input. pull_request_target is a governance boundary that many teams treat as a convenience flag, and that is where the control failure begins. Practitioners need to separate untrusted contribution handling from privileged release automation.

Command injection in workflows is an identity problem as much as an application problem: the workflow is acting with borrowed authority from the repository, its secrets, and its tokens. Once a pipeline can publish, deploy, or modify code on behalf of the project, it effectively becomes a non-human identity that needs lifecycle, scope, and approval governance. The security question is who or what is allowed to speak for the repository at execution time.

Checkout-before-execute is the named failure mode here: untrusted source code is being placed into a privileged execution path and then treated as trusted build input. That failure mode combines weak input handling, over-broad token scope, and hidden third-party action behaviour into one control gap. The practical conclusion is to govern checkout provenance and execution context together, not as separate reviews.

Secret exposure in CI/CD is persistent because the same token often does too much work: once a workflow can read secrets, write contents, or publish packages, a single injection point becomes a full compromise path. This article shows why scope limitation matters more than post-facto detection when the attacker can act inside the trusted pipeline itself. Teams should assume every privileged workflow is a potential abuse path until proven otherwise.

GitHub Actions needs NHI-style governance: workflow identities, action tokens, and build permissions should be inventoried, scoped, and revoked like any other machine credential estate. That framing aligns naturally with OWASP-NHI and access-control discipline, because the artifact doing the work is not human and should not inherit human trust. Treat the pipeline as a governed identity surface, not just a developer utility.

What this signals

Checkout-before-execute is the pattern to watch: once a privileged workflow checks out untrusted pull request code and then runs build or release commands, the pipeline has stopped being a passive automation layer and become an execution surface. That changes how teams should review CI permissions, because the question is no longer only whether the workflow builds correctly, but whether it can be induced to act on attacker-controlled code.

GitHub Actions governance should now be treated as part of identity lifecycle management for machine credentials. The workflow identity, the token scope, and the action chain all define who can act on the repository, and that authority needs inventory, review, and revocation logic just like any other NHI estate.

For practitioners

• Audit pull_request_target usage Inventory every workflow triggered by pull_request_target and classify whether it truly needs base-branch privileges, secrets, or write access.
• Eliminate unsafe context interpolation Replace direct ${{ github.event.* }} insertion into run steps with shell-safe variable handling, quoting, and explicit sanitisation for any user-controlled field.
• Restrict token permissions by default Set GITHUB_TOKEN to the minimum permissions required for each job, and remove write scope from workflows that only need read access.
• Separate untrusted checkout from privileged execution Do not run publish, deploy, or release commands on code checked out from an untrusted pull request head branch in the same privileged job.
• Review third-party actions before execution Treat marketplace actions as executable dependencies and verify what they do when pointed at user-controlled code or repository content.

Key takeaways

• GitHub Actions becomes materially risky when privileged workflows process untrusted input without strong boundary controls.
• The article shows how command injection, unsafe checkout, and broad token scope can combine into downstream supply chain compromise.
• The control that matters most is separating untrusted contribution handling from privileged execution, while tightening token permissions and input handling.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• Command injection: Command injection occurs when attacker-controlled data is inserted into a shell command and changes what the process executes. In AI tooling, that often happens through wrappers, plugins, or installation flows that turn paths or prompts into shell strings. The impact is privilege abuse through the process’s inherited authority.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity with a focus on practical control design. It helps security and identity practitioners apply the same discipline to machine credentials, workflow access, and non-human trust boundaries.