What breaks when GitHub Actions workflows interpolate untrusted input into shell commands?

When untrusted input is expanded inside a run block, the runner may execute attacker-controlled shell content before the workflow authors expect it. That can expose the repository token, allow forged commits or releases, and trigger downstream publishing jobs. The core failure is treating comments, titles, or branch names as safe command arguments when they are not.

Why This Matters for Security Teams

Workflow injection in GitHub Actions is a supply chain problem, not just a scripting mistake. Once untrusted text reaches a run block, the boundary between workflow logic and attacker input disappears, and the runner executes whatever shell syntax is embedded in that value. That can turn routine automation into token theft, release tampering, or lateral movement into build and publishing systems. The control objective is consistent with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where input handling and least privilege intersect.

Practitioners often miss this because the dangerous input is not always a classic form field. It can be a pull request title, issue comment, branch name, or any event payload that seems operationally harmless. The workflow may look safe during review because the script reads naturally, yet shell interpolation converts data into executable instructions at runtime. In practice, many security teams encounter this only after a malicious pull request or release event has already reached a privileged runner, rather than through intentional review of shell boundaries.

How It Works in Practice

The failure mode appears when workflow authors place event data directly into shell context, for example inside run steps that echo, parse, or branch on values without strict quoting. The shell interprets metacharacters, command substitutions, and line breaks before the workflow can treat the value as plain text. This is especially dangerous in GitHub-hosted runners because the default trust assumptions are often broader than the actual event source.

Security teams should treat every externally influenced field as hostile until it has been validated and safely encoded. That usually means moving away from inline shell assembly and toward fixed command arguments, environment variables, or purpose-built actions that do not invoke a shell for data handling. The most reliable pattern is to separate control flow from data flow.

• Use environment variables for data, not direct shell interpolation in run blocks.
• Quote variables defensively, and do not assume quoting alone defeats command injection in every shell.
• Prefer actions that accept structured inputs instead of concatenated command strings.
• Reduce token scope so that a failed workflow step cannot immediately become a repository takeover.
• Review whether event sources such as pull requests from forks should ever reach privileged jobs.

At the governance layer, this is an access control issue as much as a code hygiene issue. The repository token, deploy credentials, and release permissions should be segmented so that a single unsafe step cannot touch signing, publishing, or environment promotion. Guidance from the OWASP GitHub Actions Security Cheat Sheet aligns well with this approach, especially around untrusted inputs, secrets handling, and reduced privilege. These controls tend to break down when workflows mix privileged release logic with event-driven automation from untrusted contributors because the same job inherits both execution power and attacker-controlled data.

Common Variations and Edge Cases

Tighter command handling often increases workflow complexity, so organisations must balance safety against developer convenience and pipeline speed. There is no universal standard for every shell pattern yet, but current guidance suggests treating any text from the event payload as untrusted unless it has been explicitly normalised and constrained.

Some edge cases are easy to miss. A branch name may be safe in one context and dangerous in another if it is passed into a shell, while a JSON payload may appear structured but still contain values that break parsing or alter command meaning. Self-hosted runners raise the stakes further because a successful injection may reach internal networks, cached credentials, or persistent tooling. The OWASP Command Injection Defense Cheat Sheet is useful here, but it should be applied with workflow-specific care rather than copied verbatim from application code patterns.

Best practice is evolving around safer defaults such as reduced-token jobs, isolated release workflows, and explicit approval gates for publishing actions. Where organisations need to process untrusted input, the safer pattern is to validate against an allowlist, pass the value as data only, and keep any privileged action in a separate job that never sees raw user-controlled text. The CISA secure software development guidance is relevant because this is ultimately a software delivery integrity issue, not just a CI scripting concern.

Related resources from NHI Mgmt Group

• What breaks when GitHub Actions workflows run untrusted pull requests with write access?
• What breaks when GitHub Actions workflows are reachable from outside the organisation?
• What breaks when GitHub Actions workflows are treated as low-risk automation?
• What breaks when pull_request_target is used to run untrusted code in GitHub Actions?