Workflow injection is a technique where attacker-controlled input is placed into a CI/CD workflow so it executes unwanted commands. It often appears through pull requests, comments, issue fields, or dispatch events. The risk is remote code execution inside the build environment with access to sensitive tokens and artifacts.
Expanded Definition
Workflow injection is best understood as a CI/CD control failure, not just a scripting bug. It occurs when untrusted text from pull requests, issue comments, dispatch payloads, or similar events is interpolated into a workflow step that the runner executes. In practice, that can turn routine automation into code execution with the pipeline’s own identity, secrets, and artifact access. The security boundary is the workflow engine, the runner, and the trust assumptions around event data. Guidance varies across vendors on how much sanitisation is sufficient, so teams should treat all externally influenced fields as hostile until explicitly constrained. For broader identity and governance context, NHI Management Group discusses how secrets exposure and service account sprawl drive blast radius in the Ultimate Guide to Non-Human Identities, while the NIST Cybersecurity Framework 2.0 frames the need for protective controls around execution environments. The most common misapplication is assuming a workflow is safe because the repository is private, which occurs when untrusted inputs are still allowed to reach command, shell, or expression evaluation.
Examples and Use Cases
Implementing workflow protections rigorously often introduces friction for developers, because stronger validation and approval gates can slow automation and require more explicit event handling.
- A pull request title or body is echoed into a shell command, letting an attacker inject extra arguments or commands during CI execution.
- An issue comment triggers a workflow that parses the comment content and passes it into a script without sanitisation, creating a path to remote code execution.
- A GitHub Actions job checks out code from an untrusted branch and then reuses repository secrets in later steps, a pattern highlighted by the GitHub Action tj-actions Supply Chain Attack.
- A dispatch event carries JSON fields into build commands, and a malformed value changes the intended command sequence or exfiltrates tokens.
- A release workflow processes artifact metadata from upstream jobs, but the metadata was attacker-influenced earlier in the pipeline and is trusted too late.
In standards terms, the NIST Cybersecurity Framework 2.0 supports the discipline of protecting execution paths, while NHI Management Group research shows why pipeline trust decisions matter: 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools. That exposure makes workflow injection especially dangerous because the injected step is often one token away from broader compromise, and because the attacker may inherit the build system’s reach into other services.
Why It Matters in NHI Security
Workflow injection is an NHI problem because CI/CD systems frequently operate as powerful non-human identities. They authenticate to package registries, cloud APIs, test environments, signing services, and artifact stores, often with broad, persistent permissions. When an attacker can steer a workflow into executing unintended commands, the impact is rarely limited to one build. It can expose secrets, sign malicious artifacts, tamper with releases, or pivot into downstream systems that trust the pipeline. This is why the issue belongs in NHI governance alongside credential rotation, least privilege, and artifact integrity. NHI Management Group notes that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which makes pipeline compromise a direct business risk rather than a theoretical hardening concern. The right control mindset is to minimise trust in event payloads, isolate privileged steps, and ensure secrets are unavailable to untrusted workflow paths. Organisations typically encounter the consequence only after a build token is abused or a release is altered, at which point workflow 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 Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Workflow injection often exposes or misuses secrets handled by CI/CD identities. |
| OWASP Agentic AI Top 10 | AI-04 | Untrusted input steering execution is a core prompt and workflow abuse pattern. |
| NIST CSF 2.0 | PR.AC-3 | Access enforcement for workflow identities maps to controlling execution authority. |
| NIST Zero Trust (SP 800-207) | N/A | Zero Trust reduces implicit trust in pipeline events and build runners. |
| NIST AI RMF | GV-4 | Governance requires identifying and managing untrusted inputs that alter execution. |
Restrict secret access in workflows and verify that untrusted events cannot reach privileged steps.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
