Notifications
Clear all
Topic starter
20/08/2026 6:05 pm
TL;DR: GitHub Actions workflows triggered by pull_request_target can expose write access and secrets to untrusted input, creating a direct path to command injection, credential theft, and downstream supply chain compromise, according to Sonar’s analysis. The real governance problem is not just unsafe syntax, but assuming CI/CD automation can be trusted before input handling and permission scope are verified.
NHIMG editorial — based on content published by Sonar: GitHub Actions command injection, code execution, and supply chain risk analysis
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Sonar's analysis of GitHub Actions command injection and supply chain risk →
GitHub Actions command injection: are your workflows safe enough?
Explore further
20/08/2026 6:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub Actions command injection exposes supply chain credentials
