GitHub has released actions/checkout v7 with a new default protection aimed at one of the most persistent GitHub Actions supply chain risks: privileged workflows that check out and execute code from untrusted pull requests.

The change makes actions/checkout refuse common “pwn request” patterns when workflows run under pull_request_target or certain workflow_run events. These workflows execute in the context of the base repository, giving them access to the base repo’s GITHUB_TOKEN, secrets, default-branch cache access, and runner environment. When they also check out code from an unreviewed pull request from a fork, attacker-controlled code can run with the workflow’s full privileges.

GitHub said the new behavior is available now in actions/checkout@v7 and will be backported to all currently supported major versions on July 16, 2026. Workflows pinned to floating major tags such as actions/checkout@v4 will receive the protection automatically. Workflows pinned to a specific SHA, minor, or patch version will need to upgrade through Dependabot or another update process.

GitHub Finally Blocks a Long-Known pull_request_target Risk#

The risk GitHub is addressing has been public for years. In 2021, GitHub Security Lab warned that combining pull_request_target with an explicit checkout of an untrusted pull request can allow malicious PR authors to steal repository secrets or gain write permissions to the target repository.

pull_request_target was designed for trusted automation around pull requests, such as labeling, commenting, or applying project metadata. It runs the workflow definition from the target repository so maintainers can safely automate actions that require elevated permissions. But the checkout step controls which code actually lands in the runner workspace. If it pulls code from a forked pull request, the workflow can end up running attacker-controlled code with the base repository’s privileges.

That distinction has repeatedly confused maintainers. The workflow file may come from a trusted branch, while the scripts, package manifests, tests, or build commands it executes may come from an attacker-controlled fork. Once that happens, ordinary CI steps can become the attacker’s entry point. A dependency install, build command, test script, or local helper script may be enough to run attacker-controlled code inside a privileged workflow.

GitHub had already started tightening this area before the checkout change. In November 2025, it announced changes to pull_request_target and environment branch protection behavior, citing workflows that continued to run vulnerable versions from non-default branches even after maintainers fixed the default branch. GitHub’s own security hardening guidance for Actions has also long warned maintainers to treat untrusted input and privileged workflow execution carefully.

Recent Supply Chain Attacks Exploited Privileged PR Workflows#

Recent supply chain incidents show how GitHub Actions misconfigurations can turn a pull request workflow into a path for package compromise.

In the Nx supply chain attack, the project’s advisory described how a vulnerable PR validation workflow was used to trigger a more privileged publishing workflow. The publish workflow had access to the npm token used to release Nx packages, and the attacker modified workflow behavior to send that token to a webhook.

During the second wave of Shai-Hulud, PostHog disclosed that the attack began with a pull request that modified a script executed by a workflow handling external contributions. The workflow had been changed to use pull_request_target so it could automatically assign reviewers for forked contributions. The attacker used that path to steal a bot personal access token, then used that access to steal additional GitHub secrets, including an npm publishing token.

The TanStack compromise later showed another variation, chaining a pull_request_target pwn request with GitHub Actions cache poisoning across the fork-to-base repository boundary and runtime extraction of an OIDC token from the GitHub Actions runner process. The attacker published 84 malicious versions across 42 @tanstack/* packages without stealing a long-lived npm token.

The vulnerable behavior was widely understood by researchers, documented in hardening guidance, and detectable by static analysis, but it still kept appearing in production workflows. In open source projects with active external contributions, pull_request_target is commonly used for pull request automation that needs elevated permissions, such as labeling, triage, or authenticated status checks. The danger comes when that same privileged workflow also checks out code from an untrusted pull request. In many vulnerable workflows, the risky part is a small checkout configuration change buried in otherwise routine CI logic.

GitHub Now Blocks Unsafe Fork Checkouts#

With actions/checkout v7, GitHub is blocking the most common unsafe form of this pattern by default. In pull_request_target workflows, and in workflow_run workflows where the original event was a pull request event, checkout will refuse to fetch fork pull request code when the pull request comes from a fork and the configuration resolves to the fork repository, the pull request head or merge ref, or the fork pull request head or merge commit SHA.

GitHub lists examples such as:

ref: refs/pull/${{ github.event.pull_request.number }}/merge

ref: ${{ github.event.pull_request.head.sha }}

repository: ${{ github.event.pull_request.head.repo.full_name }}

Those are exactly the kinds of inputs maintainers have used when they wanted a privileged workflow to inspect or test the changes proposed by an external contributor. Under the new default, those checkouts fail unless the workflow explicitly opts out.

GitHub is also adding an allow-unsafe-pr-checkout input for workflows that intentionally need this behavior. The name is deliberately blunt, which should make it easier to spot in code review and static analysis. For teams that choose to opt out, the flag should be treated as a security-sensitive exception, not a normal compatibility setting.

GitHub Tightens the Default#

After a year of large-scale npm compromises tied to abused GitHub Actions workflows, GitHub is finally closing one of the most obvious paths from untrusted pull request code to privileged CI execution.

The protection in this update only covers checkouts performed through actions/checkout. A workflow can still introduce the same class of vulnerability by using git, the GitHub CLI, a custom script, or another action to pull attacker-controlled code and execute it inside a privileged context. The protection also does not cover unrelated third-party repositories passed to repository:, and it does not block pwn request patterns introduced through other event types, such as issue_comment.

That makes this a guardrail, not a complete solution for Actions security. Workflows that run with secrets, write permissions, deployment permissions, or OIDC publishing access still need careful review. In particular, maintainers should examine any workflow that combines privileged triggers with package installation, build scripts, local actions, test commands, generated artifacts, or cache restore/save behavior.

TanStack also showed the limits of Trusted Publishing as a CI/CD defense. The attacker did not steal an npm token or compromise the publish workflow itself; malware running inside the release workflow minted an OIDC token from the runner and published directly to npm.

The checkout update follows GitHub’s earlier changes to pull_request_target behavior in late 2025, when it moved to ensure those events use the default branch for workflow source and reference.

For maintainers, the immediate step is to update actions/checkout where versions are pinned too narrowly to receive the July 16 backport. For security teams, the longer-term task is to look beyond checkout itself: privileged pull request workflows that fetch untrusted refs, restore shared caches, execute package lifecycle scripts, or run local code before trust has been established.