It can be safe, but only if the workflow never checks out or executes code from the pull request. pull_request_target runs from the base branch with repository write access, so the danger comes from mixing that privilege with untrusted code or text. For labels and comments, keep it minimal.
Why people use it
On the plain pull_request trigger, workflows for pull requests from forks get limited permissions, so a labeler cannot write labels. The pull_request_target trigger solves that: GitHub's event reference says it runs on the base side, and notes that it runs even when the pull request has a merge conflict, unlike pull_request. It also warns you to understand the security risks before using it.
What the hardening guide says
GitHub's security hardening guide states that pull_request_target and workflow_run, when used with checkout of an untrusted pull request, expose the repository to compromise. These workflows are privileged: they can have repository write access and share caches with other privileged triggers. The guide says workflows using these triggers must not explicitly check out untrusted code, including code from forks. It advises avoiding pull_request_target when it is not necessary, and suggests workflow_run for privilege separation.
Safe versus unsafe
| Pattern | Verdict |
|---|---|
| Match changed file names to labels, no checkout | Generally acceptable |
| Post a fixed comment such as a checklist | Acceptable |
| Check out the pull request head and run its tests or scripts | Unsafe |
| Build the pull request code with secrets available | Unsafe |
| Put the pull request title into a shell command | Unsafe, see injection |
Rules for a label or comment workflow
- No
actions/checkoutof the pull request head. If you need file names, use the API. - Set minimal
permissions, for example pull requests write and contents read. See least privilege token permissions. - Pass titles, bodies and branch names only through environment variables. See preventing script injection.
- Do not expose secrets beyond the token the job needs.
- Keep the workflow file small and under code owners review. Because it runs from the base branch, edits from a pull request do not affect it until merged, which is a protection worth keeping.
Known quirks
The labeler README notes that a pull request that introduces the labeler cannot be labeled by itself, since the run uses the base branch, and an outdated base config can make later runs fail. Plan the first merge with that in mind.
When to pick something else
If you need to run code from the pull request, use pull_request and accept limited permissions. If you need a privileged follow up, the guide's route is a two stage design: an unprivileged workflow does the work and uploads results, and a separate workflow_run workflow reads the result as data. Even then, the guide says to treat artifacts from other workflows with caution, so validate them. See auto-labeling pull requests.
Quick check
Does pull_request_target give fork pull requests secrets?
It runs on the base side with repository privileges, which is exactly why untrusted code must never run in it.
Can a labeler be safe on this trigger?
Yes, when it only reads file names, has minimal permissions and never checks out the pull request code.
Sources
- GitHub Docs: security hardening for GitHub Actions
- GitHub Docs: events that trigger workflows
- actions/labeler README
Safeguard's pipeline policies and gates can add checks to pull requests without running untrusted code in a privileged context of your own. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
