GitHub Actions command injection exposes supply chain credentials

At a glance

What this is: This is an analysis of GitHub Actions command injection and code execution paths that can expose repository secrets and publishing tokens.

Why it matters: It matters because CI/CD workflows often sit outside classic IAM review cycles, yet they can hold privileged credentials and become a practical entry point for NHI abuse and supply chain compromise.

👉 Read Sonar's analysis of GitHub Actions command injection and supply chain risk

Context

GitHub Actions becomes a security problem when workflow logic treats untrusted pull request data as if it were safe shell input. The issue is not automation itself, but the combination of inherited repository permissions, exposed secrets, and workflow triggers that execute code before trust is established. In identity terms, this is a machine access governance problem as much as a software supply chain problem.

The Sonar material shows three recurring failure modes: unsafe interpolation, elevated pull_request_target execution, and third-party action use against attacker-controlled code. Those patterns matter to IAM and PAM teams because CI/CD systems often hold high-value non-human identities such as tokens, signing credentials, and publishing rights. The starting position described here is common in modern software delivery, not exceptional.

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 GitHub Actions workflows create supply chain risk for CI/CD credentials?

A: Because many workflows hold tokens that can publish releases, sign artifacts, or reach deployment systems. If an attacker can influence the workflow logic, they may steal those credentials or use them to modify downstream packages. CI/CD identity is often more powerful than teams realise, and its compromise can propagate far beyond the originating repository.

Q: How do security teams know if a workflow is exposed to command injection?

A: Look for any run step that interpolates pull request titles, issue bodies, branch names, labels, or other user-controlled values directly into shell commands. If the same job can read secrets or write repository state, the risk is materially higher. A safe workflow separates untrusted input handling from privileged execution and avoids direct shell interpretation.

Q: Who is accountable when a workflow token is abused in a release pipeline?

A: Accountability sits with the team that owns the workflow, the repository maintainers, and the platform security function that defines token scope and review policy. Release automation needs explicit ownership because a compromised CI/CD identity can become a supply chain incident, not just a build failure. Governance should require traceable approvals for every privileged workflow path.

Technical breakdown

Why pull_request_target changes the trust boundary

GitHub Actions workflows triggered by pull_request_target run in the context of the base repository, not the untrusted contributor branch. That means the workflow can access repository secrets and may receive a more permissive GITHUB_TOKEN than a standard pull_request run. If the workflow then uses pull request metadata such as branch names, titles, or issue text inside a shell command, the trust boundary collapses. The security problem is the mismatch between where the code came from and where the workflow executes.

Practical implication: Treat pull_request_target as privileged execution and require explicit review for every step that consumes untrusted input.

How command injection happens in workflow steps

Command injection in GitHub Actions usually appears when workflow expressions or shell commands interpolate user-controlled values directly into run steps. GitHub context fields such as title, body, head_ref, and message are not safe by default because they can carry attacker-controlled payloads. The safe pattern is to pass data through environment variables or other quoting mechanisms so the shell receives data as data, not as executable syntax. This is a control failure in input handling, not a platform defect alone.

Practical implication: Validate every workflow variable that can originate from a user or pull request before it reaches a shell interpreter.

Why checkout plus third-party actions can become code execution

The more dangerous pattern is not always explicit shell injection. A workflow can check out untrusted code from a contributor repository and then invoke an action or command that executes that code as part of the build process. In that case, the attacker does not need to break out of a shell string because the workflow itself grants execution. This is especially risky when actions are chained with write permissions, because the runner can modify release artifacts, publish packages, or exfiltrate tokens during the job.

Practical implication: Separate code review from code execution and block workflows that run untrusted heads with write-capable permissions.

Threat narrative

Attacker objective: The attacker wants to execute code in a privileged workflow long enough to steal publishing or access tokens and weaponise the build pipeline.

1. Entry occurs when an attacker submits malicious pull request metadata or untrusted code into a GitHub Actions workflow that processes it without sanitization.
2. Escalation happens when pull_request_target or similar privileged triggers run with write access and inherited secrets, allowing the attacker to turn input handling into execution or token theft.
3. Impact is downstream supply chain compromise, including stolen publishing credentials, malicious package releases, and credential harvesting across dependent environments.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 workflows are now NHI governance surfaces. CI/CD tokens, release credentials, and runner permissions are non-human identities that often sit outside formal IAM ownership. When those identities can write to repositories or publish packages, workflow security becomes a lifecycle and privilege problem, not just a developer hygiene issue. Teams should treat workflow permissions as governed identities with clear ownership, scope, and revocation rules.

pull_request_target creates a privileged execution trap. The issue is not simply that the trigger is dangerous, but that teams often assume pull request context is safe enough for elevated execution. That assumption fails when untrusted data, repository checkout, and secret-bearing jobs are combined. The pattern fits OWASP Non-Human Identity Top 10 concerns around secret exposure and overprivilege, and it should push practitioners to re-evaluate which workflows are allowed to inherit write access.

Command injection in pipelines is a control composition failure. Shell quoting, action trust, and token scoping are often managed as separate tasks, but attackers exploit the gaps between them. This is the kind of failure that NIST CSF and CIS Controls both try to reduce through access governance, secure configuration, and continuous monitoring. The practitioner conclusion is clear: if a workflow can both interpret input and reach privileged secrets, it needs stronger separation of duties.

Software supply chain compromise now starts with workflow identity, not just code signing. The Nx example shows that a single CI/CD token can become a launch point for package poisoning and credential theft at scale. That broadens the attack surface from source code to build-time identity, which is exactly where many enterprises still lack visibility. Teams should regard pipeline credentials as high-risk assets with the same scrutiny they apply to production access.

Secure pipeline design must assume untrusted contributors by default. Open source and public contribution models make it unrealistic to rely on trust in user input. The governing concept here is the execution boundary gap, where review happens after access to the runner has already been granted. Practitioners should design for isolation first and only then add automation convenience.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, showing how often machine identities remain outside effective governance.
• That visibility gap is why teams should pair workflow analysis with Top 10 NHI Issues and treat CI/CD credentials as governed identities.

What this signals

Workflow identities will increasingly sit inside the NHI blast radius. CI/CD tokens, release keys, and automation permissions behave like privileged non-human identities, so teams need the same ownership, rotation, and offboarding discipline they apply to service accounts. A useful next step is to map workflow credentials against the control expectations in OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix.

Execution boundary gap: this is the point where a workflow can both accept attacker-controlled input and reach privileged secrets before any meaningful trust check occurs. Once teams recognise that boundary, they can redesign pipeline architecture around isolation, least privilege, and explicit handoff points instead of relying on trigger-level trust.

This topic will push security programmes to converge DevSecOps review with identity governance. The practical shift is from scanning for bad syntax to controlling who or what can execute with write-capable credentials, when, and under which branch or repository conditions.

For practitioners

• Audit every pull_request_target workflow Inventory workflows that run on pull_request_target, review whether they touch secrets or publish artifacts, and flag any job that consumes branch names, titles, bodies, or other user-controlled fields. Prioritise repositories with release, signing, or package publishing privileges.
• Move untrusted data out of shell context Pass contributor-controlled values through properly quoted environment variables or safe APIs, and never interpolate them directly into run steps. Test the workflow with malicious payloads in title, body, and head_ref fields to verify that the shell cannot interpret them.
• Restrict GITHUB_TOKEN permissions by job Set the minimum required permissions at the workflow and job level, and remove write access from jobs that do not need it. For release paths, separate build, test, and publish stages so untrusted input cannot reach a privileged token in the same execution path.
• Block checkout of untrusted heads in privileged jobs Do not combine pull_request_target with a checkout of the contributor's head branch when the same job can access secrets or perform writes. If you need to inspect untrusted code, isolate that step from any job that can publish, sign, or modify repository state.
• Apply workflow-specific static analysis Use dedicated GitHub Actions analysis rules in CI so command injection, unsafe expression interpolation, and dangerous trigger combinations are caught before merge. Pair that scanning with manual review for any workflow that runs third-party actions on user-controlled code.

Key takeaways

• GitHub Actions can turn untrusted pull request data into privileged execution when workflows are written without strict input handling and token scoping.
• The real risk is downstream supply chain compromise, because CI/CD identities can publish packages, modify artefacts, and expose secrets at scale.
• Teams need to govern workflow permissions as non-human identities, not just as build automation, or the same mistake will keep reappearing in different forms.

Key terms

• 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.
• Workflow-Derived Secret Exposure: The accidental storage of credentials, tokens or certificates inside operational records created for support or collaboration. These secrets are often embedded during troubleshooting and then persist in tickets, attachments or scripts long after the original purpose has passed.
• Command Injection In Pipelines: A vulnerability where attacker-controlled input is interpreted as shell syntax or executable command text inside a build or automation job. It is especially dangerous in CI/CD because the job may already have access to source code, secrets, and release permissions.
• Build-time identity: Build-time identity is the set of service accounts, tokens, and permissions used by CI/CD systems, testing tools, and deployment automation. It matters because these identities often carry production access and can turn development speed into an access-control problem if they are over-privileged or poorly governed.

What's in the full article

Sonar's full article covers the operational detail this post intentionally leaves for the source:

• Workflow-by-workflow examples showing how command injection entered real GitHub Actions jobs
• The exact SonarQube analysis patterns used to flag unsafe interpolation and execution paths
• Redacted but concrete vulnerable examples from open-source projects, including remediation context
• Timeline details for the disclosed issues, fixes, and published advisories

👉 Sonar's full post covers the vulnerable workflow patterns, remediation examples, and incident context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect workflow credentials, service accounts, and access governance into one operating model.