Why do pull_request_target workflows create more risk than standard pull request workflows?

pull_request_target runs in the base repository context, which can expose secrets and write-enabled tokens to code that came from a fork. That makes it suitable for metadata tasks, but risky for any workflow that executes contributor-controlled code or checks out the pull request head.

Why This Matters for Security Teams

pull_request_target is dangerous because it executes in the trust boundary of the base repository, not the contributor’s fork. That changes the blast radius from “review untrusted code” to “run untrusted code with repository context, often including secrets, write tokens, or deploy permissions.” Standard pull request workflows are safer because they keep forked code separated from privileged context until a maintainer explicitly merges it.

This is the same pattern NHI teams see whenever identity and execution are coupled too loosely. A workflow token is an NHI with authority, and if its scope is broader than the task, the workflow becomes an access path rather than an automation control. Current guidance from NIST Cybersecurity Framework 2.0 reinforces least privilege and controlled execution, while Ultimate Guide to NHIs — Why NHI Security Matters Now shows why over-privileged machine identities routinely create hidden exposure.

In practice, many security teams encounter token theft or repository tampering only after a contributor-controlled workflow has already used a privileged context.

How It Works in Practice

With standard pull request workflows, the event is designed to test or validate untrusted changes with reduced privileges. By contrast, pull_request_target loads the workflow from the base branch and runs it with the base repository’s permissions. That means the YAML file, environment secrets, and default token behavior are inherited from the trusted side, even when the triggering change came from a fork.

The core risk is not the event name itself but what the workflow does after it starts. If it checks out the pull request head, runs scripts from the contributor, or passes secrets into build steps, the untrusted content can influence privileged execution. This is why security guidance increasingly treats CI/CD as an NHI governance problem: the pipeline identity should be narrowly scoped, short lived, and bound to the exact task being performed. NHI programs documented in Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both emphasize that long-lived or over-scoped machine credentials are a recurring root cause.

• Use pull_request_target only for metadata-only actions such as labeling, triage, or comment automation.
• Never check out or execute contributor-controlled code in the same job that has secrets or write access.
• Prefer separate jobs: one unprivileged job for validation, one tightly controlled job for trusted follow-up actions.
• Reduce token scope, disable unnecessary write permissions, and use short-lived credentials wherever possible.
• Review reusable workflows and composite actions as part of the trust boundary, not as harmless helpers.

Where possible, treat the workflow token like any other production NHI and rotate or revoke access after the task is complete. These controls tend to break down in repositories that auto-merge dependency updates or execute third-party actions without pinning because privilege and code provenance stop being clearly separated.

Common Variations and Edge Cases

Tighter workflow isolation often increases developer friction, requiring organisations to balance contributor convenience against repository integrity. That tradeoff is real, especially in large projects that rely on external contributors or automated release pipelines.

There is no universal standard for every GitHub Actions design, but current guidance suggests a conservative rule: if a job can be influenced by forked code, it should not have secrets, write permissions, or deployment authority. Metadata-only use cases are the safest fit for pull_request_target, while any step that builds, tests, or executes code should assume the input is adversarial. This aligns with the broader NHI governance view in OWASP NHI Top 10, where execution context and identity scope must be evaluated together, not separately.

Edge cases appear when workflows are split across jobs, when maintainers manually rerun failed checks, or when a job reads artifacts produced by an earlier untrusted step. Those patterns can quietly reintroduce privilege even if the initial trigger seems safe. The safest operational rule is simple: if untrusted content can shape the command line, the file system, or the token used by the job, the workflow has crossed from review into execution.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• When does shift left create more risk than it reduces?
• Should organisations allow pull_request_target for automated dependency workflows?
• Why do source-code disclosure flaws create identity risk as well as application risk?