# What goes wrong
pull_request_target runs in the context of your base branch, not the pull request. That makes it privileged: it can share the main-branch cache, gets write permissions, and can read your secrets. If that workflow checks out the PR's code and runs it, a forked pull request is now running attacker code with your secrets in scope. This is one of the most exploited Actions misconfigurations.
# The rule
Never check out or execute untrusted code inside a privileged trigger. Treat pull_request_target and workflow_run with suspicion every time you see them.
# Safe patterns
1. Split the work. Run build and test on the unprivileged pull_request trigger. Reserve pull_request_target for only the things that need privilege, like labeling or commenting, without checking out the PR.
2. Or gate on a label. The privileged workflow does nothing until a maintainer adds a trusted label, and it checks out the base commit only, never the PR head.
3. If a privileged workflow must inspect PR content, fetch just the data it needs through the API (title, diff stats) instead of checking out the whole tree.
# Checks
- Search workflows for pull_request_target paired with a checkout of the PR ref. Each hit is a finding until proven safe.
- For every privileged workflow, ask what untrusted input can reach it and what the least privilege it needs really is.