GitHub Actions Command Injection

How GitHub Actions Command Injection Happens

GitHub Actions command injection occurs when a workflow passes attacker-controlled text into a shell, runner command, or expression context without strict separation between data and code. In practice, that means a pull request title, issue body, branch name, commit message, or other workflow input can change how the runner executes the step.

The core danger is not limited to one syntax mistake. Any place where a workflow interpolates untrusted input into run commands, shell variables, composite actions, or expressions can become an execution boundary failure. The same pattern also appears when scripts build command lines dynamically instead of treating each argument as data.

Why It Is Dangerous in CI/CD

CI/CD runners often have broad visibility into source code, signing material, deployment tokens, package credentials, and other sensitive values needed to build and ship software. If command injection succeeds, the attacker may execute arbitrary commands inside that build context, read environment variables, tamper with artifacts, or pivot into downstream systems that trust the pipeline.

This is especially dangerous because workflows are frequently triggered by external contributions and automation events. A malicious payload can hide inside content that looks harmless to reviewers, then execute only when the job reaches a vulnerable interpolation point. The risk is amplified when jobs run with default permissions that are wider than the step actually needs.

Common Exposure Paths and Failure Patterns

The most common failure pattern is treating workflow data as if it were already safe for shell evaluation. That includes concatenating values into commands, using unsafe quoting, relying on shell metacharacters to remain inert, or mixing expression syntax with shell syntax in the same line.

Exposure review should focus on where inputs enter the workflow, how they are transformed, and which jobs can reach sensitive secrets or publishing privileges. A useful starting point is a dedicated Command Injection Guide, which covers CI/CD command injection, detection signals, and safer process APIs, and the broader Web Application Attacks Guide, which places command injection alongside related injection patterns. For workflow-specific hardening, the CI/CD Pipeline Identity Security Guide explains why token scope, untrusted builds, and pinned actions matter in pipeline design.

Detection and Safer Workflow Design

Detection starts with reviewing workflow files for shell interpolation, unsafe string concatenation, and steps that execute on attacker-influenced event data. Look for commands that use unquoted variables, generated scripts, or indirect evaluation paths, then confirm whether those steps can reach secrets, release tooling, or privileged APIs.

Safer design means reducing the amount of executable text that comes from workflow inputs. Use explicit argument passing, avoid shell evaluation where possible, and keep untrusted data in parameters rather than command strings. The same defensive mindset appears in the OWASP Top 10 A05 Guide, which treats OS command injection as a high-priority injection class, and in external guidance such as the OWASP Top 10, which frames injection as a persistent application-security risk.

Risk and Threat Considerations

Command injection in GitHub Actions can turn a routine automation step into a code-execution event with access to source, secrets, and release credentials. The impact ranges from workflow manipulation and data theft to poisoned releases and broader supply-chain compromise if the runner can publish artifacts or push commits.

Failure mechanism: Untrusted workflow input is interpolated into a shell command or expression, the shell interprets it as code, and the attacker gains execution inside the runner context.

Impact: An attacker can exfiltrate secrets, modify build outputs, tamper with release artifacts, or use the job’s trust relationships to extend compromise beyond the original workflow.

Practitioner Guidance

Why practitioners should care: Treat every workflow input as hostile until it is explicitly constrained. The key judgement is whether a step needs shell execution at all; if it does, the command structure should be fixed and the data should be passed separately from the executable text.

Common misunderstanding: Quoting alone is not a complete defence when the surrounding workflow still builds commands dynamically. The safer standard is to remove unnecessary shell evaluation, minimise job permissions, and ensure untrusted data cannot influence the command parser.

Related resources from NHI Mgmt Group

• What are the signs that a GitHub Actions workflow may be vulnerable to command injection?
• How should security teams prevent shell injection in GitHub Actions workflows that interpolate untrusted context data?
• How should security teams reduce the risk of command injection in CI/CD workflows that call third-party actions?
• How do you prevent shell injection in GitHub Actions run steps?