Why do workflow triggers like pull_request_target and workflow_run increase supply chain risk?

Why these triggers are riskier than ordinary workflow events

Triggers such as pull_request_target and workflow_run are dangerous because they can run in a trusted context that has secrets, release permissions, or repository write access, even when the event was initiated by untrusted code. That breaks the normal expectation that untrusted changes only get untrusted execution. In practice, the security boundary is the trigger path, not the code owner.

That matters most when the workflow does more than inspect metadata. If it checks out attacker-influenced content, processes artifacts, or shells out to scripts, the workflow can turn a trusted runner into a delivery path for theft, tampering, or release abuse.

A useful way to think about it is that the trigger changes who gets authority before the code is proven safe. OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the same control principle: limit what can authenticate or act with elevated privilege until trust is established.

How the abuse path works in practice

pull_request_target runs against the target repository context, so a pull request from a fork can trigger a workflow with permissions that belong to the base repository. If the job then checks out the untrusted branch, the attacker can place code, scripts, or configuration in the execution path and have it run with stronger privileges than the source deserves.

workflow_run is similarly risky because it lets a downstream workflow inherit trust from an upstream workflow rather than from the content that ultimately gets processed. If the upstream step builds or packages attacker-controlled input, the downstream step may consume artifacts or metadata that appear legitimate but are already shaped for abuse.

This is why supply chain attacks so often pivot through CI. The vulnerable step is not always the first build job, it is the moment trusted automation starts handling untrusted material as if it were safe. SLSA is useful here because it treats provenance and build integrity as first-class controls, while NIST SSDF (SP 800-218) pushes teams to harden the build and release process itself.

Where the real supply chain damage happens

The highest impact usually comes from a workflow that can read secrets, modify release assets, or publish artifacts after processing untrusted input. Once an attacker can reach a publishing token, a package signing step, or a deployment credential, the compromise can move beyond a single repository into downstream users, builds, or production systems.

That is why these triggers are not just “risky” in the abstract, they expand the blast radius of any mistake in input handling. A poisoned PR, a malicious artifact, or a crafted dependency payload can become a trusted internal action path. When that happens, the attacker is no longer trying to break in through the front door, they are using the workflow itself as the authority chain.

For practitioners, the key control question is whether the job that has secrets or write access also touches untrusted content in the same execution path. Nx s1ngularity attack 2025 and reviewdog Action compromise 2025 both show how a trusted GitHub Actions path can become a secret-exposure and release-poisoning event when trust and execution are mixed.

Risk and Threat Considerations

These triggers create a classic trusted-path abuse problem. The workflow is trusted to run with elevated authority, but the inputs may come from a fork, a prior job, or an artifact that an attacker can influence. The result is a control gap where malicious content can inherit trusted execution without ever becoming trusted code.

Failure mechanism: The workflow combines elevated permissions with attacker-influenced checkout, artifact consumption, or script execution, allowing the attacker to ride the trusted runner to secret access, token theft, or release tampering.

Impact: The compromise can leak credentials, poison packages or release artifacts, and propagate into downstream consumers, CI systems, or production deployments.

Practitioner Guidance

What to verify: Check whether any job triggered by pull_request_target or workflow_run can both access secrets and process untrusted input. If yes, treat it as a privileged code path and require explicit separation between trust establishment and execution.

Decision rule: If a workflow needs repository write access, deployment credentials, or signing material, do not let it checkout or execute attacker-controlled content in the same job. Keep the trusted job narrowly scoped, and move untrusted validation into a lower-privilege path.

What good looks like: The trusted workflow only handles metadata, approvals, or safe promotion logic, while untrusted code is tested in a context with no secret access and no release authority.

Practitioner takeaway: The danger is not the trigger name itself, it is the combination of elevated authority and untrusted material in one execution path. Break that combination, or the workflow becomes a supply chain control plane for the attacker.

Related resources from NHI Mgmt Group

• Why do workflow_run pipelines create supply chain risk when they process pull request results?
• Why do fork based pull request workflows increase supply chain risk in cloud native development?
• Why do pull_request_target and fork-based workflows increase the risk of secrets exposure in CI/CD pipelines?
• Why do clone and pull request attacks on popular repositories create such a serious supply chain risk?