What breaks when a GitHub Actions workflow with pull_request_target can reach publish secrets?

Where pull_request_target stops being “just CI”

pull_request_target changes the trust boundary because it runs in the context of the base repository, not the fork. That means the workflow can read repository secrets and write back to the repository even when the pull request content is untrusted. Once those two facts meet, the job is no longer neutral automation, it is a privileged execution path that must be treated like production access.

That boundary shift is why workflow design matters more than the file change itself. A carefully reviewed patch can still be dangerous if the workflow evaluates attacker-controlled input before it finishes with secrets, publishes artifacts, or grants write-capable tokens.

In practice, the same pattern appears across supply-chain incidents where a workflow or maintainer token was enough to reach publishing infrastructure. A useful reference point is CI/CD Pipeline Identity Security Guide, which frames publishing rights, untrusted builds, and keyless federation as trust-boundary problems rather than simple automation choices.

What actually breaks when secrets are reachable

The broken control is segregation between untrusted code review and trusted release authority. If a pull request can influence a job that reads publish secrets, the attacker can turn review-time execution into secret access, artifact tampering, or release impersonation. The direct consequence is that the workflow inherits the privileges of the repository owner while still processing attacker-controlled content.

That is exactly the failure mode behind leaked tokens, poisoned releases, and malicious package publication. Once a secret is available inside the job, the attacker does not need to “hack GitHub” in the abstract; they only need the workflow to expose a credential that can authenticate to a downstream service.

For readers who want the broader supply-chain context, tj-actions/changed-files compromise 2025 shows how an action compromise can expose CI/CD secrets at scale, and Nx s1ngularity attack 2025 shows how a GitHub Actions weakness can cascade into credential theft and malicious publishing.

How to think about the control failure

The key distinction is between validation and authority. Pull request review validates code quality, but it does not by itself authorize that code to run with publishing credentials. If the workflow mixes those two steps, the control collapses: untrusted input is effectively granted trusted execution.

That is why the safest design is to keep secret-bearing publish jobs out of the pull request execution path, or to isolate them so that attacker-controlled content cannot change what is executed after the secret is loaded. The goal is not to eliminate automation, but to make sure the automation cannot cross the boundary from review to release without an explicit trust decision.

For a concrete identity and secret-handling lens, Secrets Management Guide explains why secretless and short-lived patterns reduce blast radius, while API Key Management Guide is useful when the exposed credential is a publish token rather than a human login.

Risk and Threat Considerations

When publish secrets are reachable from pull_request_target, the main risk is credential abuse, because the attacker can aim at the secret rather than the source code. That can lead to package poisoning, release tampering, or lateral movement into other systems that trust the same token family.

Failure mechanism: attacker-controlled pull request content influences a privileged workflow step after the repository secret has been loaded, so the secret can be exfiltrated or used to publish malicious output.

Impact: the compromise can extend beyond one repository, because publishing credentials often reach package registries, signing systems, deployment pipelines, or other automation that trusts the same identity.

Practitioner Guidance

What to verify: confirm that no job triggered by untrusted pull request content can read publish secrets, write tags, or access release credentials. If a workflow must inspect forked content, separate that inspection from any step that can authenticate to a registry or deployment target.

Decision rule: if the job can reach a production-facing secret, treat the workflow as a privileged release path and require the same review discipline you would use for a deployment gate. If the job only needs test access, issue a different credential with no publish scope.

What good looks like: untrusted pull requests can test, lint, and comment, but they cannot cross into artifact publication unless a trusted maintainer or trusted automation path explicitly grants that privilege.

Practitioner takeaway: the dangerous part is not pull_request_target by itself, it is combining untrusted input with publish authority in the same runtime context.

Related resources from NHI Mgmt Group

• What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
• What breaks when GitHub Actions workflows trust attacker controlled branch names or pull request metadata?
• What happens when a malicious pull request is merged into an overprivileged GitHub Actions workflow?
• What should security teams do first after a GitHub Actions workflow in a public repository is found vulnerable to pull request abuse?