GitHub pull_request_target Security: Safe PR Workflows

Keep privileged PR automation away from untrusted code

GitHub’s event reference says `pull_request_target` runs in the context of the base repository and describes it as useful for activity such as labeling or commenting on pull requests from forks. [1] The same section warns that the trigger should not be used when a workflow needs to build or run pull-request code. [1]

The risk is not that the trigger is always wrong. The risk is mixing a privileged repository context with code or artifacts controlled by a pull-request author.

`pull_request_target` fits metadata work that does not run PR code

GitHub Security Lab explains that `pull_request_target` was introduced for scenarios where a workflow needs elevated access to process a pull request, such as labeling or commenting, without checking out and executing the pull-request content. [2]

That distinction creates a simple review rule: a `pull_request_target` job should read pull-request metadata, apply labels, post comments, request reviews, or update status with carefully handled data. It should not run package install scripts, build scripts, test commands, repository-local tooling from the PR branch, or binaries produced by the PR branch.

• Safer shape: label or comment using base-repository workflow code and bounded event fields.
• Risky shape: check out a fork branch and run its install, build, test, or generation commands in the privileged job.

Explicit PR checkout changes the trust boundary

GitHub Security Lab’s warning is narrow and important: combining `pull_request_target` with an explicit checkout of an untrusted pull request is dangerous because it can expose repository write permissions or secrets to attacker-controlled code. [2]

OpenSSF Scorecard encodes the same family of risk in its Dangerous-Workflow check, which looks for `pull_request_target` or `workflow_run` used with explicit pull-request checkout. [4] Scorecard says those workflows can have write permission and target-repository secrets, and that pull-request authors may compromise the repository when their code is checked out and run in that context. [4]

Split untrusted work from privileged follow-up

GitHub Security Lab describes a safer pattern for cases that need both untrusted pull-request processing and privileged follow-up: run the untrusted code with `pull_request`, store narrow results as artifacts, then use `workflow_run` for the privileged step that comments or reports status. [2]

GitHub’s events reference also warns that running untrusted code on `workflow_run` may create vulnerabilities such as cache poisoning or unintended access to write privileges or secrets. [1] That means the split-workflow pattern is not a license to run PR-built binaries later. Treat artifacts from untrusted work as data, validate what is inside them, and keep privileged follow-up jobs small.

• Untrusted workflow: build or test the fork PR with reduced permissions and no repository secrets.
• Privileged workflow: read a constrained artifact such as a PR number, coverage summary, or status file, then comment or update status.

Token permissions should make privilege visible

GitHub documents `permissions` as the workflow syntax for modifying default `GITHUB_TOKEN` access, including `read-all`, `write-all`, `{}`, and per-permission `read`, `write`, or `none`. [3] GitHub also documents that unspecified permissions are set to `none` once a workflow specifies any permission. [3]

OpenSSF Scorecard awards its highest Token-Permissions result when workflows declare read-only permissions at the top level and put required write permissions at the run level. [4] That is a useful review posture for `pull_request_target`: the workflow should show exactly which job needs write access and why.

When a `pull_request_target` job has write access, the job name and steps should explain the need. If the job only comments, it should not also have package, deployment, contents write, or broader scopes.

A first audit can start with six searches

Search workflow YAML for `pull_request_target`, `workflow_run`, `actions/checkout`, `github.event.pull_request.head`, `permissions:`, and `secrets.`. Those strings map to the source-backed risk areas in this guide: privileged PR triggers, explicit PR checkout, token scope, and secret access. [1] [2] [3] [4]

For a local review queue, run gha-guard against the repository and inspect any `pull_request_target`, permissions, checkout, timeout, or shell-context findings before merging workflow changes.

This article is informational and is not a substitute for a security review of your own workflows, repositories, or cloud accounts.

CI Tripwire has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 4 entries, primary platform, security-lab, and project documentation, last reviewed 2026-06-07.