The trust boundary breaks because the pipeline may still be privileged while the script content is untrusted. In that case, the base workflow runs attacker-modified shell code, which is indirect poisoned pipeline execution. This can expose secrets, alter build behaviour, or turn a normal validation job into a command execution path. The failure is not the pull request itself, but the script reference crossing trust zones.
Where the Trust Boundary Actually Breaks
The key failure is not that the pull request exists, it is that a privileged workflow consumes code from an untrusted branch as if it were part of the trusted base. That turns a review or validation step into a code execution boundary crossing, so the pipeline’s permissions, network reach, and secret access become available to attacker-controlled script content.
Once that happens, the script reference becomes the trust pivot. Even if the rest of the workflow is unchanged, the execution context is no longer equivalent to running base-branch code, because the command source can now influence build steps, artifact contents, and any credentials or tokens exposed to the job.
- Review the exact checkout, path, and ref resolution logic before assuming a PR job is isolated.
- Treat any script loaded from the PR branch as untrusted input, even when the workflow file itself sits on the protected base branch.
- Assume job secrets, tokens, and write-capable integrations are in scope if the runner can execute attacker-modified shell code.
Why This Becomes Indirect Poisoned Pipeline Execution
This pattern is a supply-chain integrity failure inside CI/CD. The pipeline may be intended to test code, but the trust decision is made at the reference layer: a trusted workflow invokes a script from a source the reviewer did not approve in the same security context. That is why the issue is often described as indirect poisoned pipeline execution rather than a normal pull request review risk.
The practical consequence is that a harmless-looking script change can alter build behaviour, inject malicious commands, or exfiltrate data during routine automation. The attack does not need to defeat the code review process if the workflow itself already grants execution authority to content fetched from the PR branch.
For a concrete parallel, NHIMG’s Reviewdog GitHub Action supply chain attack shows how action or pipeline trust assumptions can be abused to reach secrets, while the GitHub Action tj-actions Supply Chain Attack shows how CI/CD secrets become exposed once a trusted automation path is subverted.
- Separate review of workflow logic from execution of branch-supplied scripts.
- Prefer immutable, reviewed, and pinned automation inputs for privileged jobs.
- Reduce the blast radius of any job that must process PR-controlled content.
Risk and Threat Considerations
This pattern is dangerous because it combines two properties that should rarely coexist: elevated pipeline privilege and attacker-controlled script content. The result is a high-value execution path that can leak secrets, tamper with artifacts, or pivot into downstream systems if the runner can reach them.
Failure mechanism: the workflow resolves a script from the pull request branch, then executes it inside a trusted job context that has broader permissions than the PR author should ever receive.
Impact: attackers can turn a validation run into credential exposure, build tampering, repository compromise, or a stepping stone for broader CI/CD abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 5 — Account Management | Privileged CI jobs must not expose unnecessary account or token access. |
| CIS Control 6 — Access Control Management | The issue is a privilege boundary crossing from trusted workflow to untrusted script. | |
| CIS Control 16 — Application Software Security | Scripts from PR branches are software inputs that can alter build and execution behavior. | |
| Recommendation — Restrict CI job accounts to the minimum access needed for the exact pipeline step. Enforce least privilege on workflow tokens, runners, and deployment permissions. Treat branch-supplied scripts as untrusted code and validate the execution path before running them. | ||
| NIST CSF 2.0 | PR.AC — Access Control | A trusted pipeline invoking PR code is an access-control and privilege-boundary problem. |
| PR.DS — Data Security | The execution path can expose secrets or sensitive build data to attacker-controlled code. | |
| DE.CM — Continuous Monitoring | Abuse of pipeline trust often appears as anomalous script execution or secret access. | |
| Recommendation — Separate trusted workflow execution from untrusted PR-controlled inputs. Protect secrets and sensitive data from jobs that process untrusted branch content. Monitor CI jobs for unexpected script sources, token use, and outbound data movement. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | This is a pipeline trust violation where attacker-controlled code is executed through a trusted path. |
| T1059 — Command and Scripting Interpreter | The core abuse is attacker-modified shell code running in the pipeline context. | |
| Recommendation — Hunt for compromised build inputs and untrusted code execution inside the delivery pipeline. Detect unexpected interpreter use in CI jobs that should only run approved build logic. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | The risk includes leaking tokens and secrets from a privileged CI job. |
| NHI-03 — Overprivileged Identities | The break occurs when a privileged automation identity executes untrusted content. | |
| Recommendation — Keep CI secrets out of jobs that execute pull-request-controlled scripts. Reduce privileges on pipeline identities before allowing them to process untrusted code. | ||
Practitioner Guidance
What to verify: confirm whether the workflow file, checkout step, and script path all resolve from the protected base branch rather than the PR branch, and inspect whether the job receives any write token, deploy token, or secret that the PR author should not influence.
Decision rule: if the job must run code from the PR branch, treat it as untrusted execution and remove sensitive permissions, secrets, and outbound reach before you rely on the result. If the job needs full privilege, it should not execute branch-supplied scripts at all.
Practitioner takeaway: the control objective is not “block pull requests”, it is “stop privileged automation from executing attacker-authored code under a trusted context”.
Related resources from NHI Mgmt Group
- What breaks when GitHub Actions workflows trust attacker controlled branch names or pull request metadata?
- What breaks when teams rely only on main branch scanning and skip pull request analysis?
- What breaks when untrusted pull request content is executed in a workflow?
- What breaks when AML pipeline scripts can be modified in linked storage?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
