GitHub Blocks 'Pwn Requests' in Actions Checkout

GitHub has had enough of pwn requests. From 18 June 2026, the new version of actions/checkout, the workhorse step that pulls a repo into a workflow runner, will refuse by default to fetch code from a forked pull request when the workflow is triggered by pull_request_target or a related workflow_run event. The change gets backported to older supported versions on 16 July 2026.

What a pwn request actually is

For anyone who hasn't tripped over this one, pull_request_target is the trigger that runs in the context of the base repository, with its secrets and a read-write GITHUB_TOKEN, even when the pull request comes from an outside fork. Combine that with a checkout of the fork's code and you have effectively handed a stranger the keys to your pipeline. Submit a PR, run your scripts inside someone else's privileged workflow, walk off with the token. That is the entire class of attack, and it has a name in the wild: the pwn request.

Not a theoretical problem

This is not academic. The s1ngularity campaign against Nx packages used exactly this pattern. So did the recent compromises of PostHog, TanStack, and the kubernetes-el Emacs package. Maintainers who assumed pull_request_target was a harmless trigger for slapping labels on PRs discovered, often publicly, that it could quietly execute whatever a contributor's fork wanted to run.

The pattern is appealing to attackers for a reason. It does not require a stolen credential, a phishing lure, or a supply chain pivot through a dependency. It just requires a project that accepts pull requests and a maintainer who wired up the trigger without reading the small print.

What changes on 18 June 2026

The new behaviour in actions/checkout blocks the most obvious version of the trick: checking out the head or merge commit of a fork PR inside a privileged event. Workflows that need the old behaviour can set allow-unsafe-pr-checkout to true, which is the kind of flag name that should give anyone pause before flipping it.

GitHub and Socket, who have both written this up, are clear that this is a guardrail rather than a cure. A few things it does not cover:

• Checkouts pointed at arbitrary third-party repositories are still allowed.
• Other triggers that can carry attacker-controlled input, like issue_comment, are untouched.
• Workflows that pull untrusted code through their own scripts, rather than the checkout action, are outside the scope of the change.

What maintainers should actually do

If you maintain Actions workflows, the next few weeks are a good moment to take stock. Audit where pull_request_target is genuinely needed, because most of the time plain pull_request will do the job with none of the risk. Trim the permissions on anything that runs with secrets attached, so that even a successful pwn request walks away with less. And treat that allow-unsafe-pr-checkout flag as a conversation, not a quick fix, when someone inevitably suggests setting it to keep an existing pipeline running.

The underlying lesson is the unglamorous one. Default behaviours in CI tooling shape the security posture of half the open-source world, and the gap between what a setting does and what a maintainer thinks it does is where attackers live.