What breaks when CI/CD workflows can execute attacker-controlled pull requests with elevated credentials?

The workflow stops being a build control and becomes a privilege boundary failure. Once untrusted PR content can touch org-scoped tokens, release paths, or marketplace credentials, the attacker can move from code review into repository takeover, artifact tampering, and package publishing. The issue is trust inheritance, not just a bad script.

How elevated PR access turns a workflow into a trust boundary problem

The break is architectural, not cosmetic. A CI/CD pipeline is supposed to treat pull-request content as untrusted input until it has been reviewed and promoted. Once the workflow can run attacker-controlled PR code with elevated credentials, it no longer enforces a separation between review-time code and release-time authority, so the pipeline itself becomes part of the attack surface.

This failure usually shows up when the job inherits permissions that were meant for trusted branches, deployment steps, or maintainer-only automation. At that point, the PR author is no longer only proposing code, they are being handed execution context that can modify repository state, reach package registries, or manipulate downstream build outputs.

The practical consequence is that the security question shifts from “is the script safe?” to “what authority does untrusted code inherit?” That is why attacks against build systems often succeed even when the code change itself looks ordinary, because the workflow is the privileged object, not just the repository contents.

What attacker-controlled PRs can do once they inherit build authority

With elevated tokens or secrets in scope, a malicious PR can move from code execution to persistence and supply-chain abuse. The attacker may alter release artifacts, publish a tampered package, exfiltrate signing material, or inject changes that survive beyond the PR merge decision. A useful way to think about the failure is that the build system stops authenticating intent and starts laundering trust.

That is why this pattern often leads to repository takeover or package compromise rather than a one-off build break. If the workflow can write back to the repo, update branches, or access release infrastructure, the PR can be used to create durable control, not merely to run arbitrary commands once.

For teams that want a deeper look at how pipeline exposure turns into secret loss, the Guide to the Secret Sprawl Challenge is a useful companion because it shows how CI/CD exposure and secret leakage reinforce each other. When release authority is the asset, not just the script, secret handling becomes a build integrity issue.

The same trust-inheritance failure is visible in real-world pipeline compromise cases, including CI/CD pipeline exploitation case study and reviewdog Action compromise 2025, where control over the workflow or its dependencies created a path from code review into broader system access.

Why this becomes supply-chain compromise instead of a simple workflow bug

Once a PR can reach credentials, the blast radius extends beyond the repository. Elevated build permissions can let an attacker tamper with artifacts, poison caches, alter release metadata, or publish malicious dependencies that downstream consumers trust. That is why the issue is often better described as release-path compromise than as a single misconfigured job.

If the workflow also touches package registries or signing steps, the attacker can move from transient execution to durable distribution. In practice, that is the point where the attack stops being about one pipeline and starts affecting every system that trusts its outputs.

Controls for this problem are strongest when they focus on provenance and trust separation. Build steps that consume untrusted input should not be the same steps that can publish, sign, or promote artifacts. The more the workflow combines review, build, and release authority, the easier it is for an attacker to convert one accepted PR into multiple compromised trust anchors.

That is also why artifact integrity guidance matters here. If the pipeline can be driven by untrusted input, the surrounding release process should be designed so that tampering is detectable even when execution is permitted. The SLSA framework is relevant because it frames build provenance and artifact integrity as first-class supply-chain controls.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply Chain Levels for Software Artifacts	Build provenance and artifact integrity are central when PRs can affect release outputs.
Recommendation — Adopt provenance checks and separate untrusted build steps from trusted release steps.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Elevated PR workflows fail when untrusted jobs inherit more access than needed.
Recommendation — Restrict workflow permissions to the minimum required for each job.
OWASP ASVS	V15 — Secure Coding and Architecture	CI/CD trust boundary failures reflect insecure architecture between review and release paths.
Recommendation — Separate untrusted input handling from privileged release functions in the pipeline.
CIS Controls v8	CIS-5 — Account Management	Pipeline identities and secrets must be governed tightly when build jobs can act with privilege.
Recommendation — Inventory and constrain automation accounts and revoke unneeded access promptly.

Practitioner Guidance

What to verify: Check whether PR jobs inherit any token, secret, or role that can write to the repo, publish artifacts, or access deployment systems. If they do, treat that as a privilege boundary failure, not a code-quality issue.

Decision rule: If untrusted PR content must run, keep it inside a read-only, non-release context and separate verification from any step that can mutate state, sign artifacts, or publish packages.

What good looks like: The PR path can test code, but it cannot inherit release authority, and any move from review to publish requires a separate trusted promotion step with explicit human or controlled automation approval.

Practitioner takeaway: The key question is not whether the workflow can execute PRs, but whether untrusted PR code can ever inherit the authority to change what others trust.