GitHub hardens actions / checkout to stop pwn requests and protect the supply chain

GitHub has decided to harden one of the most recurrent routes of attack against the software supply chain: from June 18, 2026 the official action actions / checkout stop accepting common "pwn requests" patterns that explode the trigger by default pull _ request _ target to run malicious code with base repository privileges. The measure will be applied first in the most recent version (v7) and, as announced by the company, will be back to the main supported versions on July 16, 2026.

The key technical modification is that actions / checkout v7 refuses to bring the code of the request when it comes from a fork and certain conditions are met- for example when the repository parameter points to the fork and the ref corresponds to refs / pull /... / head or refs / pull /... / merge - unless the flow author explicitly chooses to disable the protection using allow-unsafe-pr-checkout = true. The action also applies this restriction in workflow _ run executions that are related to pull _ request events.

Understanding why this matters requires remembering how pull _ request _ target works: that event runs in the context of the default branch of the base repository and, by design, loads a GITHUB _ TOKEN with reading and writing permits and can access secrets. If in that flow the code sent by a contributor from a fork is downloaded and executed, an attacker can enter scripts that steal tokens, poison caches or abuse privileges to publish malicious changes. Recent attacks that exploited similar vectors affected sensitive projects and packages, including incidents that compromised ecosystems such as Nx and popular packages from other organizations.

The GitHub initiative significantly reduces the risk of the most common pattern of pwn requests, but is not a complete solution. The new protection only intervenes when the checkout is done by actions / checkout: nothing prevents a flow from running git, using GitHub's CLI or any other external action to obtain unreliable code, or blocks other events that can be used in an abusive way. Therefore, there are still risk vectors that require human review and additional controls.

For teams and security officials this news should be translated into concrete and immediate actions. The first is to update the flows that use actions / checkout and test the v7 version; review the workflows that depend on pull _ request _ target and ask if they really need to run with secrets or with high permissions. In many cases the safe alternative is to replace pull _ request _ target by pull _ request where the basic repository privileges are not required, or to strictly limit the GITHUB _ TOKEN permissions by the key permissions in the workflow.

In addition to changing triggers and versions, it is appropriate to adopt operational practices: to require human reviews before workflows are run with privileges over PRs of forks, to avoid the direct consumption of secrets in jobs that process external inputs and not to enable allow-unsafe-pr-check out except in very justified circumstances and with compensatory controls. It is also recommended to consolidate reusable actions that reside only in the base repository and to implement branch protection and review policies to avoid automatic executions without supervision.

From the point of view of supply chain governance, this improvement is welcome because it acts as a guarrail that prevents common configuration errors. However, teams should view this as part of a broader approach that includes workflow audits, reduction of the area of privileges and the use of modern mechanisms such as OIDC for deployments (which minimize static secret dependence).

If you want to review the implementation or update your flows, see the official action repository in GitHub to follow the launches: actions / checkout in GitHub. To understand the implications of the event that causes the greatest concerns, official documentation about pull _ request _ target explains why this trigger needs caution: copy _ request _ target. It is also useful to read the GitHub Actions hardening guides to apply additional controls: Security harassment for GitHub Actions.

In short, the update of actions / checkout is a positive step that blocks the most exploited vector of pwn requests, but does not replace the need for broader operational and technical policies: audit workflows, minimize permissions, avoid running unrevised code at privileged events and update actions regularly must be part of the routine to protect the supply chain.