pull_request_target is a GitHub Actions trigger that runs in the context of the target repository rather than the incoming pull request repository. That means it can access target-repository secrets and write permissions. It is useful for some review workflows, but it becomes dangerous if the workflow checks out and executes untrusted incoming code.
Expanded Definition
pull_request_target is a GitHub Actions event that executes workflows with the permissions and secret access of the target repository, not the contributor’s fork. That distinction matters because the workflow may evaluate untrusted pull request content while still holding write access, deployment credentials, or other repository-scoped secrets. For a governance lens, this is less about CI convenience and more about trust boundary management.
Used safely, the trigger supports review automation, labelling, comment-based checks, and other repository maintenance tasks where the workflow logic is fixed and does not execute attacker-controlled code. Used unsafely, it creates an opportunity for secret exposure or privileged action through commands, scripts, or checkout steps that process the incoming branch. GitHub’s own documentation on workflow permissions and event behavior should be read alongside the NIST Cybersecurity Framework 2.0 so teams treat the trigger as a control decision, not just a build setting.
Definitions are consistent on the core risk, but implementation guidance varies across vendors and internal engineering standards. The most common misapplication is using pull_request_target to run tests or scripts from the incoming branch, which occurs when teams confuse repository context with code trust.
Examples and Use Cases
Implementing pull_request_target rigorously often introduces workflow complexity, requiring organisations to balance automation and review speed against the risk of executing untrusted changes with elevated permissions.
- Automated labelling or triage of external pull requests, where the workflow only reads metadata and writes comments or labels to the target repository.
- Security review workflows that fetch patch data for analysis without checking out and executing contributor code, reducing the chance of secret disclosure.
- Documentation or policy checks that operate on repository files maintained by trusted maintainers, while keeping privileged steps separate from untrusted content.
- Merge gating workflows that require signed approvals before privileged actions occur, aligning the trigger with a controlled review path rather than direct execution.
- Repository hygiene tasks that update issue state or metadata in response to a pull request, using fixed workflow logic instead of branch-authored scripts.
GitHub’s security guidance for Actions should be interpreted with the same caution applied to privileged automation in other environments, especially where secrets are present. Teams that handle external contributions should compare their workflow design with broader secure automation principles and keep privileged steps isolated from untrusted payloads.
Why It Matters for Security Teams
Security teams need to treat pull_request_target as a privileged execution path because the failure mode is not just a broken build, but a compromise of repository secrets, tokens, or downstream systems. Once a workflow can write back to the repository, update releases, or call deployment tooling, the trigger effectively becomes part of the organisation’s access control model. That makes it relevant to identity, secret handling, and least privilege as much as to CI/CD.
This is where identity governance intersects with software supply chain security: an attacker does not need to compromise a human account if they can influence a workflow that already runs with trusted authority. The practical control question is whether the job ever evaluates untrusted code, and whether secrets are exposed before trust is established. Guidance from GitHub Actions event documentation and secure coding guidance from OWASP Top 10 are useful reference points when designing these workflows.
Organisations typically encounter the consequences only after a malicious pull request or a poisoned dependency path exposes privileged workflow behavior, at which point pull_request_target becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Privileged workflow access must be limited to trusted paths and authenticated actions. |
| OWASP Non-Human Identity Top 10 | Privileged automation can expose NHI secrets and tokens if untrusted code runs in-context. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit trust decisions before granting workflow execution authority. | |
| NIST SP 800-53 Rev 5 | SA-11 | Secure development and testing controls apply to workflow logic that can affect privileged systems. |
| NIST SP 800-63 | Credential assurance is relevant when workflow tokens or secrets are used for repository operations. |
Restrict privileged CI/CD steps to trusted contexts and verify no untrusted code can inherit elevated access.
Related resources from NHI Mgmt Group
- Should organisations allow pull_request_target for automated dependency workflows?
- What do security teams get wrong about pull_request_target workflows?
- Why do pull_request_target workflows create more risk than standard pull request workflows?
- What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
