Command injection in CI/CD

Command injection in CI/CD happens when untrusted text is interpreted as executable workflow syntax or shell input. In GitHub Actions, that can allow titles, comments, or branch names to alter environment variables, command paths, or job behaviour without a separate malware payload.

Expanded Definition

command injection in CI/CD is broader than classic shell injection because the attacker may influence not only a command line, but also workflow logic, runner context, and downstream job steps. In practice, untrusted input from pull request titles, issue comments, branch names, tags, build parameters, or artifact metadata can be expanded by a shell, templating engine, or pipeline expression language. This matters most where pipelines execute with privileged service accounts, publish artifacts, or access secrets and deployment credentials. NIST’s NIST Cybersecurity Framework 2.0 helps frame the issue as a resilience and execution-integrity problem rather than only a code-quality defect.

Definitions vary across vendors on whether adjacent failures such as expression injection, workflow poisoning, or unsafe parameter interpolation are grouped under the same label. NHI Management Group treats the term as any case where CI/CD control text becomes executable behavior without a trust boundary. The most common misapplication is assuming branch or comment content is harmless because it is “just metadata,” which occurs when pipeline authors pass untrusted strings into shell, YAML, or script contexts without quoting or validation.

Examples and Use Cases

Implementing CI/CD protections rigorously often introduces stricter input handling and workflow constraints, requiring organisations to weigh developer convenience against pipeline safety and secret exposure reduction.

• A pull request title is interpolated into a shell command, allowing an attacker to append extra flags or commands during a build job.
• A GitHub Actions workflow reads branch names into environment variables and later uses them in a deployment script, changing the target or behaviour of the release step.
• A comment-driven automation job accepts untrusted text from an issue or pull request and passes it to a script without escaping, triggering command execution inside the runner.
• A malformed artifact label is used in a packaging command, causing the pipeline to invoke a different executable path or overwrite a release output.

This pattern is closely related to the pipeline abuse scenarios described in NHI Management Group’s CI/CD pipeline exploitation case study and to the misuse patterns seen in the Reviewdog GitHub Action supply chain attack. For workflow hardening, teams often look to guidance such as NIST Cybersecurity Framework 2.0 to tighten execution controls and reduce trust in inbound text.

In secret-heavy environments, the same trust flaw can expose credentials that should never reach the runner context. NHI Management Group’s Guide to the Secret Sprawl Challenge shows why pipeline text handling and secret containment must be designed together, not separately.

Why It Matters in NHI Security

CI/CD command injection is an NHI problem because modern pipelines authenticate as identities, assume roles, and access secrets with real operational authority. When attacker-controlled text changes job behaviour, the pipeline itself becomes an identity misuse path, not just an application bug. That can lead to credential disclosure, unauthorized deployments, tampered artifacts, and persistence inside release automation. In NHI Management Group’s research on secrets exposure, The State of Secrets Sprawl 2025 reports that 15% of commit authors have leaked at least one secret in their contribution history, which underscores how often identity-adjacent workflows become security events.

The practical risk is not limited to one repository. Untrusted input may propagate from source control into build scripts, release tooling, chatops integrations, and deployment hooks, creating a chain where one injection becomes repeated misuse of privileged NHI credentials. Defenders should treat command construction as a trust boundary, apply allowlists for parameters, and separate human-authored text from executable logic. Organisationally, the issue typically becomes visible only after a runner is abused, a secret is exfiltrated, or a deployment behaves unexpectedly, at which point command injection in CI/CD becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is workload identity federation and why is it important for CI/CD security?
• How do I implement secrets scanning in a CI/CD pipeline?
• When should teams prioritise CI/CD hardening over broader secret scanning?
• How should security teams govern machine credentials across cloud and CI/CD environments?