GitHub has released version 7 of its actions/checkout action for GitHub Actions, introducing a critical security default that automatically blocks dangerous workflows exploiting the pull_request_targetcodecode event. This update directly addresses a long-standing attack vector, often called a “pwn request,” where untrusted code from a forked pull request can execute with full CI privileges, including access to the base repository’s secrets, GITHUB_TOKENcodecode, and production resources. The new behavior, which will be backported to all supported major versions by July 2026, is designed to fail fast and prevent the most common patterns of this abuse.
Understanding the “Pwn Request” Threat
The pull_request_targetcodecode event is one of the most frequently misused triggers in GitHub Actions. Unlike the standard pull_requestcodecode event, which runs with restricted permissions from the forked repository, pull_request_targetcodecode executes in the context of the base repository. This means it has full access to sensitive resources, such as deployment keys, cloud service credentials, and internal artifacts. When a maintainer checks out the head or merge commit of a pull request from an untrusted fork within this privileged context, the attacker’s code can run with those elevated permissions. This pattern has been responsible for multiple high-profile supply-chain compromises across the ecosystem.
What the GitHub Checkout v7 Update Blocks
The new actions/checkout v7 update specifically refuses to fetch code from a forked pull request when used in pull_request_targetcodecode workflows or in workflow_runcodecode jobs where the triggering event is a pull_request*codecode type. The action will fail if the repositorycodecode input resolves to the fork’s repository, if the refcodecode matches refs/pull//headcodecode or refs/pull//mergecodecode, or if the refcodecode resolves to the fork pull request’s head or merge commit SHA. This blocks common unsafe patterns like refs/pull/${{ github.event.pull_request.number }}/mergecodecode and repository: ${{ github.event.pull_request.head.repo.full_name }}codecode in privileged workflows.
By failing early, the update prevents untrusted pull request code from reaching jobs that execute sensitive commands, such as run: ./scripts/deploy.shcodecode, which might have direct access to production secrets. However, GitHub has explicitly noted that this update does not claim to eliminate every variant of pwn requests. Workflows remain vulnerable if they manually pull and execute untrusted code using runcodecode blocks that call gitcodecode or the ghcodecode CLI to fetch arbitrary refs or repositories, as those operations bypass actions/checkoutcodecode entirely.
How the Update Affects Existing Workflows
On July 16, 2026, GitHub will backport this enforcement logic into all currently supported major versions of the action. This means workflows pinned to floating tags like actions/checkout@v4codecode will automatically inherit the safer defaults without any manual change. Pipelines that pin actions/checkoutcodecode to a specific SHA, minor, or patch version will not be updated automatically and must be upgraded via Dependabot or established internal processes to benefit from the new protections.
Same-repository pull requests are unaffected by this change. The traditional pull_requestcodecode event behavior remains unchanged, ensuring that standard contribution workflows continue as usual. The update is focused on the most prevalent misuse of the pull_request_targetcodecode event, but GitHub may expand hardening to additional event types, such as issue_commentcodecode, in the future.
Opt-Out Path for Legitimate Use Cases
For scenarios where a fork’s pull request code must legitimately run with elevated trust—for example, coverage generation using private artifact registries or authenticated checks on incoming changes—GitHub provides an explicit opt-out path. After reviewing the official guidance on securely using pull_request_targetcodecode, maintainers can add the allow-unsafe-pr-checkoutcodecode input to the actions/checkoutcodecode step to re-enable fork PR checkouts in these workflows. The input name is intentionally loud and descriptive to ensure its presence is obvious during code review and static analysis, reinforcing that turning off the default protection is a conscious, high-impact security decision.
What Affected Users Should Do Now
Security-focused teams are encouraged to adopt a defense-in-depth approach. For most workflows, the recommended practice is to run untrusted fork code under the pull_requestcodecode event with restricted permissions, reserving pull_request_targetcodecode and any unsafe checkouts only for carefully audited pipelines that genuinely require access to secrets and sensitive resources. Developers should immediately review any workflows using actions/checkoutcodecode with a pull_request_targetcodecode trigger, identify any patterns that explicitly fetch fork PR refs or repositories, and either upgrade to v7 or update the input to include the safe defaults. For teams using pinned versions, a proactive update via Dependabot is the most straightforward path to securing their pipelines against this class of attack.
