A forked pull request can trigger a workflow_run event that later runs in a more privileged context. If that workflow downloads and executes poisoned artifact content, the attacker can gain privilege escalation inside the pipeline. The usual impact is secret theft, artifact tampering, or unauthorized changes to build outputs and deployment material.
Why this pipeline pattern becomes dangerous
A workflow_run trigger often executes after the original pull request has finished, which means the second pipeline can inherit a more trusted context than the untrusted fork that started it. The danger is not the trigger itself, but the moment a later job treats earlier artifacts as if they were safe inputs and then runs them with elevated permissions.
That shift in trust boundary matters because the forked PR author controls the artifact’s contents. If the downstream job downloads, unpacks, interprets, or executes that content, the attacker can turn a build dependency into an execution path and move from untrusted contribution space into privileged pipeline space.
In practice, this is a supply chain integrity problem, because the artifact becomes the delivery vehicle for malicious code or modified build material. The issue is especially sharp in CI/CD systems where the same workflow can both validate input and later publish releases, update deployment assets, or handle credentials needed for those actions.
This pattern is closely related to the kind of CI/CD compromise described in CI/CD pipeline exploitation case study, and it sits in the same failure class as the GitHub Action tj-actions Supply Chain Attack, where poisoned pipeline inputs were able to reach sensitive execution paths.
What changes when the artifact is executed instead of only inspected
The security boundary changes the moment the workflow treats the artifact as executable content rather than inert output. At that point, the downstream job is no longer just moving files between stages, it is granting code from an untrusted origin the ability to run inside a trusted automation context.
That distinction determines the blast radius. If the artifact is only archived or scanned, the impact is limited to validation risk. If it is executed, the artifact can influence subsequent commands, environment handling, generated outputs, release packaging, and any step that can read pipeline secrets or write to repositories and deployment targets.
Because the workflow_run job often has broader access than the forked PR job, the attacker can use the trusted stage to steal secrets, tamper with build artifacts, alter deployment material, or persist changes that look like normal pipeline output. This is why provenance and integrity verification are not optional when handoff occurs between workflow stages. A useful control lens here is SLSA, which centers build provenance and integrity checks for software artifacts.
Where the pipeline handles secrets, the problem also overlaps with credential governance. NHIMG’s Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which reinforces why pipeline-exposed credentials must be treated as high-value targets rather than convenient runtime inputs.
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 MITRE ATT&CK 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Privileged workflow execution can expose pipeline secrets to untrusted artifact content. |
| NHI-03 — Overprivileged Non-Human Identities | workflow_run jobs often run with broader privileges than the forked PR context. | |
| NHI-09 — Supply Chain and Third-Party Risk | A poisoned artifact from a forked PR is a supply-chain integrity problem inside CI/CD. | |
| Recommendation — Isolate secrets from untrusted workflow stages and revoke any exposed credentials immediately. Reduce workflow permissions to the minimum needed for each stage and separate build from release rights. Require provenance validation before promoting artifacts into trusted pipeline stages. | ||
| CIS Controls v8 | 8 — Audit Log Management | Pipeline execution and artifact promotion need traceable records for incident review. |
| 6 — Access Control Management | The risky condition is excessive permission when untrusted content reaches privileged jobs. | |
| 16 — Application Software Security | Untrusted artifact execution is a software supply-chain integrity failure in the build system. | |
| Recommendation — Log artifact provenance, execution, and privilege changes so suspicious pipeline activity is reviewable. Limit workflow permissions and separate untrusted build steps from privileged deployment steps. Verify artifact integrity before execution and block unsigned or unexpected build outputs. | ||
| MITRE ATT&CK | T1204 — User Execution | The attacker succeeds when a trusted pipeline job executes malicious artifact content. |
| T1552 — Unsecured Credentials | Secret theft is a primary consequence when poisoned artifacts run in privileged contexts. | |
| Recommendation — Hunt for stages where untrusted files are executed or interpreted by privileged automation. Protect secrets from pipeline stages that process untrusted artifacts and rotate exposed credentials quickly. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | The issue is a trust-boundary failure caused by overbroad access in later pipeline stages. |
| PR.DS — Data Security | Artifacts and build outputs need integrity protection before they are consumed by trusted jobs. | |
| Recommendation — Apply least-privilege access to each workflow stage and gate privileged actions behind explicit approval. Protect artifact integrity and validate content before it can influence downstream build or release data. | ||
Practitioner Guidance
What to verify: Treat every workflow_run handoff as a trust upgrade that must be explicitly justified. Verify whether the downstream job ever executes content produced by the forked PR, and if it does, require provenance checks, strict allowlists, and a clear separation between untrusted build artifacts and privileged release steps.
Decision rule: If the artifact can influence code execution, command construction, package installation, release signing, or deployment output, treat it as untrusted input until it has been validated in a context with no secret access and no write permissions.
Common mistake: Teams often secure the initial pull request workflow and assume the later workflow_run stage is safe because it is “internal.” The real risk is that the later stage is exactly where privilege, secrets, and publishing rights tend to converge.
Practitioner takeaway: The control objective is not to prevent artifact handoff, it is to ensure that no untrusted artifact can cross into a privileged runner without integrity verification and a bounded execution model.
Related resources from NHI Mgmt Group
- What breaks when untrusted pull request content is executed in a workflow?
- What happens when an untrusted pull request triggers a workflow that uses a vulnerable GitHub Action without egress controls?
- What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
- What breaks when untrusted issue or pull request content is inserted directly into an AI prompt?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
