# GitHub hardens checkout defaults for pull_request_target workflows > Actions checkout v7 will refuse common patterns that expose privileged pull_request_target jobs to untrusted pull-request code. Canonical URL: https://www.devobs.io/news/news-github-actions-safer-pull-request-target-checkout/ By: Arjun Shah Published: 2026-09-06T11:58:54.642Z Updated: 2026-09-06T11:58:54.642Z Event date: 2026-06-18 Section: Security 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](https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/) 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. ## Source references -