What do security teams get wrong about pull_request_target workflows?

Why This Matters for Security Teams

NIST Cybersecurity Framework 2.0 treats access control as a governance problem, but pull_request_target is often where that governance gets bypassed in practice. The workflow runs in a privileged repository context, which means the security question is not whether the YAML file looks trusted, but whether any step can be influenced by attacker-controlled input before privileged operations are complete. That distinction matters because CI/CD is now part of the identity surface, not just the delivery pipeline.

For NHI governance, this maps directly to the broader problem of short-lived automation identities being treated like harmless build helpers. The same pattern that exposes service accounts and API keys in other environments also appears in GitHub Actions when teams assume trigger names are sufficient safety boundaries. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the condition attackers look for when a workflow can reach secrets, deployment systems, or repository write actions. In practice, many security teams encounter abuse only after a benign-looking automation path has already been used to alter code, exfiltrate secrets, or approve a downstream release.

How It Works in Practice

The core issue with pull_request_target is that it executes against the base repository, not the attacker’s fork, so it inherits privileges that are safe only if every step is carefully constrained. Current guidance suggests treating the trigger as privileged by default and then reducing exposure through explicit checks, isolated jobs, and strict separation between untrusted and trusted actions. The safest pattern is to keep any code that parses or executes pull request content out of the privileged job entirely.

In practical terms, teams should assume the following are high-risk in a pull_request_target workflow:

• checking out untrusted pull request code before validation
• using pull request data in shell commands without sanitisation
• calling reusable workflows that can reach secrets or write permissions
• passing attacker-controlled filenames, labels, or comments into scripts
• mixing review logic and deployment logic in the same job

Security teams should instead separate the workflow into a low-privilege inspection phase and a privileged approval phase. That means validating metadata first, gating on trusted reviewers or repository rules, and only then allowing access to secrets or write-scoped tokens. For broader identity hygiene, this is consistent with the NHI lifecycle approach described in Ultimate Guide to NHIs, where permissions are intentionally short-lived and tightly scoped rather than assumed safe because they are automated.

External standards also reinforce the same direction. NIST CSF 2.0 emphasizes protecting assets through controlled access and continuous governance, while workflow-hardening guidance from the GitHub ecosystem aligns with the principle that privileges should only be available to trusted code paths. These controls tend to break down when teams let the privileged job both evaluate the pull request and act on it in the same execution path because the attacker controls the input before the trust decision is final.

Common Variations and Edge Cases

Tighter workflow controls often increase maintainer overhead, requiring organisations to balance developer speed against the risk of privileged automation abuse. That tradeoff becomes more visible in repositories with heavy contribution volume, complex reusable workflows, or multiple layers of bot-driven automation. Best practice is evolving, but there is no universal standard for this yet, especially where policy checks, code scanning, and approvals are combined in one pipeline.

One common edge case is the use of trusted-looking reusable workflows. Reuse does not remove risk if the calling workflow still supplies untrusted inputs or inherits broad permissions. Another is comment-driven automation, where a maintainer command triggers a privileged action after an attacker has already shaped the state of the pull request. Teams should also be careful with third-party actions that appear benign but can expand the execution surface inside a privileged job.

For defenders, the practical rule is simple: if a workflow can reach secrets, deployment credentials, or repository write access, it must not process untrusted code or trust attacker-controlled fields until trust has been established. That rule aligns with NHI governance in the real world, where identity, permission, and execution context must be evaluated together rather than assumed from the trigger name alone. The State of Non-Human Identity Security shows how little confidence many organisations have in securing NHIs, and pull_request_target is one more place where that gap becomes operational.

Related resources from NHI Mgmt Group

• What do security teams get wrong about browser-based phishing defence?
• What do security teams get wrong about search-based phishing?
• What do security teams get wrong about malicious ads and credential theft?
• What do security teams get wrong about valid credentials?