Why must workflows using pull_request_target be extremely careful with actions/checkout and secrets?
Select an answer to reveal the explanation.
Short Explanation and Infographic
pull_request_target is privileged base-repo context—secrets included. If you then run attacker-controlled PR code, you handed them the keys. It is not secretless, not tokenless, not schedule-only.
Full explanation below image
Full Explanation
pull_request_target is designed for workflows that need write permissions or secrets while reacting to PRs, including from forks, but it checks out the base by default and must not blithely execute untrusted build scripts from the PR head. Combining pull_request_target with checkout of the PR ref and npm install/test of that code is a classic secret-exfiltration pattern. Prefer pull_request for CI that builds contributor code without secrets, or carefully isolate privileged jobs. GITHUB_TOKEN still exists with configured permissions. This event is not limited to schedule. Security guides recommend minimizing pull_request_target usage, avoiding untrusted code execution, and using environments with protection rules for any privileged automation.