Why pull_request_target Is Risky and When to Avoid It

pull_request_target exists for a reason. It allows workflows triggered by pull requests to run in the context of the base repository, which can be helpful for labeling, commenting, and other automation that needs higher trust.

It is also one of the most common GitHub Actions security footguns.

Why it is dangerous

The danger is not the trigger alone. The danger is what teams do with it.

If a workflow triggered by pull_request_target checks out attacker-controlled code, executes scripts from the pull request, or mixes in secrets and write permissions, you can end up running privileged automation on untrusted input.

That is the core issue.

The safe question to ask

Before using pull_request_target, ask:

Do we need privileged repository context, or do we just need a pull request event?

If the answer is “we only need tests, lint, or validation,” pull_request is usually the better option.

Reasonable uses

There are cases where pull_request_target can make sense:

• adding labels
• posting comments
• managing review routing
• other metadata operations that do not execute pull request code

The keyword is metadata. The moment the workflow begins interacting with attacker-controlled files or scripts, your risk model changes.

High-risk patterns

Avoid combinations like:

• pull_request_target plus actions/checkout of the pull request head
• pull_request_target plus run: steps that execute repository scripts
• pull_request_target plus secrets or cloud credentials
• pull_request_target plus broad write permissions

This is where a convenient automation pattern becomes a privileged execution path.

Safer alternatives

Use pull_request for untrusted code paths

If a workflow needs to build, test, or analyze contributed code, run it in a lower-trust context.

Split workflows by trust boundary

One workflow can validate code from contributors. Another can handle privileged repository actions after review or on trusted branches.

Minimize the steps in privileged workflows

If pull_request_target is necessary, keep the workflow narrow. Avoid shell logic that processes contributor-controlled content, and do not fetch or execute code from the pull request unless you have a very clear isolation strategy.

What good review looks like

When you review a workflow using pull_request_target, you should be able to answer:

1. What exact job needs the trigger?
2. Does it access secrets, tokens, or write scopes?
3. Does it execute code, scripts, or files influenced by the pull request?

If that answer chain is muddy, the workflow probably needs redesign.

Bottom line

pull_request_target is not inherently wrong. It is simply more privileged than many teams realize.

The safest pattern is to reserve it for narrow repository metadata operations and keep untrusted code execution on lower-trust events. That one boundary decision eliminates a surprising amount of GitHub workflow risk.