GitHub Actions pull_request_target security: safe patterns

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.

CI Tripwire Editorial 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.