Socket: actions/checkout v7 Blocks Unsafe pull_request_target Checkouts

What it is

actions/checkout@v7 ships a default protection that refuses the most common "pwn request" checkout patterns when a workflow runs under pull_request_target, or under workflow_run where the triggering event was a pull request. These events run in the base repository's context — with its GITHUB_TOKEN, secrets, default-branch cache, and runner — so checking out fork PR code lets attacker-controlled scripts execute at full workflow privilege. The risk was first flagged by GitHub Security Lab in 2021.

How it works

The workflow definition comes from the trusted target branch, but the checkout step decides which code lands in the workspace. If that code comes from a fork PR, a routine dependency install, build, test, or helper script becomes the attacker's entry point. Under v7, checkout blocks when the config resolves to the fork repository, the PR head/merge ref, or the fork PR head/merge SHA. The blocked inputs are exactly the ones maintainers used to inspect contributor changes:

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 }}

The three cited incidents show variations: Nx — a vulnerable PR-validation workflow triggered a more privileged publish workflow holding the npm token, which was exfiltrated to a webhook. Shai-Hulud wave two (PostHog) — a PR modified a script run by a workflow that had been switched to pull_request_target for reviewer assignment; the attacker stole a bot PAT, then further secrets including an npm token. TanStack — chained a pull_request_target pwn request with cache poisoning across the fork/base boundary plus runtime OIDC-token extraction from the runner, publishing 84 malicious versions across 42 @tanstack/* packages without ever stealing a long-lived npm token.

Preconditions / Affected

Any workflow using pull_request_target (or workflow_run off a PR event) that also checks out fork PR code via the patterns above. Not affected: labeling/triage automation that never checks out untrusted code.

What to do

• Move to actions/checkout@v7, or rely on the backport landing July 16, 2026 to all supported major versions.
• Workflows pinned to floating major tags (e.g. actions/checkout@v4) get the protection automatically. Workflows pinned to a specific SHA, minor, or patch version do not — upgrade them via Dependabot or another update process.

Caveats

The block covers "the most common unsafe form" of the pattern, not every variant. It only engages for the specified events and ref/repo resolutions — other privilege-escalation paths in Actions remain out of scope. The page text is cut off before it states how a workflow can explicitly opt back in, so verify the override mechanism against GitHub's own docs before relying on it.