GitHub Hardens actions/checkout Against Pwn Request Exploits

Key points

• GitHub is updating actions/checkout to block pwn request attacks that exploit the pull_request_target workflow trigger.
• The pull_request_target trigger can run code with the workflow's full privileges, making it a target for supply chain attackers.
• The change takes effect 18 June 2026.
• Developers should update their pipelines before that date.

What is a pwn request attack?

A pwn request attack exploits the pull_request_target trigger, a GitHub Actions event that runs workflows with the repository's full permissions even when the triggering code comes from an external fork. An attacker submits a pull request carrying a malicious script; if the workflow checks out that code and runs it, the attacker inherits elevated access to secrets, tokens and the broader pipeline.

What is GitHub actually changing?

Effective 18 June 2026, the latest version of actions/checkout, GitHub's official action for pulling repository code into a runner, will refuse the patterns that make pwn request attacks work. The update targets the specific combination of pull_request_target and code checkout that lets untrusted contributor code execute with the host workflow's privileges.

This isn't GitHub discovering the problem late. We covered the same issue on 23 June 2026 in "GitHub Tightens Security to Counter Pwn Request Attacks", which reported actions/checkout v7's introduction. This update appears to formalize and extend those protections at the action level, so repositories that haven't pinned to a hardened version get the fix automatically on upgrade.

Should you worry if you're not using pull_request_target?

Not immediately. The risk is scoped to workflows using that specific trigger. But it's worth auditing your Actions configuration now: grep your .github/workflows directory for pull_request_target and check whether any of those jobs also call actions/checkout on the PR's branch rather than the base branch. That combination is the attack surface.

The broader pattern is worth watching. GitHub's npm overhaul on 11 June 2026, which blocked automatic install scripts by default, and npm's staged publishing with mandatory two-factor approval from 28 May 2026 point to a consistent push across GitHub's toolchain to tighten the supply chain at the action level, not just the policy level.

What should developers do before 18 June 2026?

Pin actions/checkout to the updated version as soon as it ships, review any workflow using pull_request_target, and scope permissions explicitly using the permissions key so no job gets more access than it needs. The Miasma incident in June 2026, in which 73 open-source projects were spiked with stealer malware via account takeover, shows what happens when the blast radius of a compromised workflow is left wide open.

The honest assessment: this is a necessary fix to a well-documented problem, and it's overdue. Hardening a single action doesn't secure the whole CI/CD surface. Teams that have left pull_request_target workflows running with default permissions should treat 18 June as a deadline, not a suggestion.