GitHub hardens checkout defaults for pull_request_target workflows

GitHub announced safer defaults for actions/checkout in workflows triggered by pull_request_target on June 18. Version 7 detects common configurations that check out untrusted pull-request code inside a job running with the target repository’s privileged context and refuses that checkout. GitHub’s security changelog calls this the “pwn request” pattern.

Trigger context and checked-out code must agree

pull_request_target is useful when a workflow needs access to base-repository secrets or permissions for labeling and comments. Its danger appears when the same job then executes code, scripts, or build configuration supplied by the contributor. The attacker controls what runs while the workflow supplies trusted credentials.

The checkout guard addresses common forms of that combination. It does not prove an entire workflow safe: a later step can download pull-request artifacts, interpolate untrusted data into a shell command, or invoke another action that fetches contributor-controlled content.

Audit the workflow, not only the action version

Search workflow files for pull_request_target and trace every input to an execution point. Jobs that only inspect metadata should avoid checking out pull-request code. Jobs that must build contributions should use the unprivileged pull_request context and receive no write token or secrets. If privileged follow-up is necessary, pass narrowly defined, verified results through a separate workflow rather than executable artifacts.

GitHub planned to backport the guard to supported major tags except v1 on July 20. Workflows pinned to a commit SHA or minor tag need an explicit update, according to the post. Preserve pinning discipline while moving to a protected release; do not switch to a floating reference merely to inherit the fix. Add a test pull request from a fork and verify that the expected safe path still works and the unsafe path fails closed.