A weakness in which attacker-controlled text is interpreted as shell syntax inside an automation step. In CI/CD, branch names, filenames, comments, and environment variables can become execution vectors when they are echoed, expanded, or passed into scripts without strict escaping and validation.
Expanded Definition
Workflow command injection happens when an automation platform treats untrusted input as executable syntax rather than inert data. It is most often seen in build pipelines, release jobs, and administrative scripts where variables such as branch names, file paths, pull request titles, or repository metadata are inserted into shell commands without strict quoting, escaping, or allowlisting. The security issue is not the presence of automation itself, but the point at which text crosses the boundary from data to command execution.
In practice, this weakness sits close to script injection and environment poisoning, but the defining feature is the workflow context: the command runs because a pipeline, runner, or orchestration step interprets attacker-controlled text inside an execution language. Guidance from NIST Cybersecurity Framework 2.0 is relevant here because it frames secure execution, access control, and governance around operational processes that should not trust uncontrolled inputs. The most common misapplication is assuming CI/CD variables are safe by default, which occurs when teams pass repository-supplied text directly into shell interpolation or command templates.
Examples and Use Cases
Implementing secure automation rigorously often introduces extra validation and formatting rules, requiring organisations to weigh pipeline convenience against the risk of remote command execution.
- A build job uses a branch name in a shell command, and an attacker creates a branch name containing shell metacharacters that alter the command flow.
- A release workflow echoes issue titles into a script, and a crafted title injects additional commands during packaging or deployment.
- An automation step passes filenames from a repository scan into a command line tool, but the filenames are not quoted and are interpreted as options or syntax.
- A self-hosted runner reads environment variables from an upstream job, and an untrusted value changes the behaviour of later steps through expansion or substitution.
- A deployment script consumes webhook payload fields without validation, and attacker-controlled text reaches the shell through a parameterized command.
These scenarios are especially dangerous in CI/CD because workflow privileges are often broader than the permissions of the user who triggered the event. NIST-aligned process controls and secure build guidance should treat pipeline inputs as untrusted until they are validated and safely encoded. For threat modelling, teams can also reference the OWASP Top 10 CI/CD Security Risks and the OWASP Cheat Sheet Series for defensive handling patterns.
Why It Matters for Security Teams
Workflow command injection turns routine automation into an execution path for an attacker, which means a low-friction developer convenience can become a high-impact compromise. Once code execution is available inside a pipeline, an adversary may steal secrets, tamper with artifacts, modify release outputs, or pivot into source control and cloud environments. That makes the issue relevant not only to application security but also to identity and secrets governance, because CI/CD jobs frequently hold tokens, API keys, signing certificates, and deployment credentials.
Security teams should treat this weakness as an identity-adjacent control problem: the workflow identity itself may be over-privileged, the secrets exposed to the job may be unnecessary, and the step boundary may be too trusting. NIST guidance on secure software and operational governance, along with NIST SP 800-53, reinforces the need for input validation, least privilege, and controlled execution environments. Organisations typically encounter the full impact only after a pipeline has already run attacker-supplied commands, at which point workflow command injection becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | Highlights access governance for workflow identities and execution paths. |
| NIST SP 800-53 Rev 5 | SI-10 | Requires input validation to prevent hostile data from becoming executable command text. |
| OWASP Non-Human Identity Top 10 | NHI guidance applies when workflow jobs use secrets, tokens, or machine identities. | |
| OWASP Agentic AI Top 10 | Agentic automation guidance maps to tool-using workflows that execute commands from input. | |
| NIST AI RMF | Relevant where AI-generated workflow text is executed by automation without review. |
Restrict pipeline privileges so untrusted input cannot reach high-impact execution steps.
Related resources from NHI Mgmt Group
- How do security teams know if a workflow is exposed to command injection?
- Why do privileged SAP accounts increase the risk of command injection and configuration abuse?
- What do teams get wrong about command injection in AI tooling?
- How should security teams prevent command injection in Java applications?
