GitHub Blocks Fork PR Checkouts in Privileged Workflows by Default in actions/checkout v7

On June 18, 2026, GitHub released v7.0.0 of its official actions/checkout action, introducing a guardrail that by default refuses fork PR checkout patterns commonly used in privileged workflows such as pull_request_target. The goal is to reduce the risk of "pwn request" attacks, in which attacker-controlled code runs in a write-privileged context. According to the official changelog, v7.0.0 applies immediately and will be backported to all currently supported major versions on July 16, 2026.

The change targets the pull_request_target event and workflow_run events whose originating event is pull_request*. For fork PRs, checkouts are blocked when repository: points to a fork repository, when ref: matches refs/pull/<number>/head or /merge, or when ref: resolves to the head or merge commit SHA of a fork PR. In concrete terms, widely used patterns such as ref: refs/pull/${{ github.event.pull_request.number }}/merge, ref: ${{ github.event.pull_request.head.sha }}, and repository: ${{ github.event.pull_request.head.repo.full_name }} are now refused. To bypass this behavior, the newly added allow-unsafe-pr-checkout: true must be explicitly specified. GitHub deliberately gave it a conspicuous, sudo-like name, leaning toward a safe-by-default posture.

The underlying issue is that pull_request_target runs with the base repository's write-capable GITHUB_TOKEN, secrets, the default branch's cache scope, and runner access. Checking out and executing code from a fork PR in that context lets attacker code run with privileges, opening the door to secret leakage or repository takeover. This is the so-called pwn request, long known as the root cause of multiple supply chain attacks. GitHub had warned about it in security resources, but this update achieves practical risk reduction by blocking the most common dangerous patterns outright. Ordinary pull_request events and same-repository PRs are unaffected.