GitHub spent most of 2026 closing off the "pwn request", the trick that let anyone who opened a pull request from a fork run code inside a project's privileged CI workflow, with its secrets in reach. New research from Wiz says the fixes are real, but the attack class has not gone away. It has moved.
In the original report, Wiz researcher Shay Berkovich maps what GitHub's changes actually block, where they stop, and what maintainers need to do before GitHub starts enforcing a new default on December 2, 2026.
Six months of fixes, one big deadline
The core problem is the pull_request_target trigger. It runs a workflow with the repository's secrets and write token, yet anyone who opens a pull request from a fork can set it off. If that workflow checks out and runs the fork's code, the attacker's code runs with the project's privileges. Wiz lays out GitHub's response:
- June 18: actions/checkout v7.0.0 blocks checking out fork code by default under untrusted triggers (pull_request_target, and workflow_run fired by pull requests).
- June 26: read-only cache tokens for untrusted triggers, to stop cache poisoning.
- July 20: the fork checkout protection is backported to v2.8.0, v3.7.0, v4.4.0, v5.1.0 and v6.1.0 (v1 is excluded).
- September 10 and 17: fine-grained cache controls, then Workflow Execution Protections with event policies and actor rules, reach general availability.
- December 2 (scheduled): GitHub begins enforcing a default event policy that blocks pull_request_target in public repositories with no explicit policy. Private and internal repositories are not affected.
Pinning to a SHA can switch the protection off
Standard supply chain advice tells teams to pin actions to an exact commit SHA rather than a mutable tag. But the backported protection lives inside the actions/checkout code itself, so a SHA that points at a release older than the July 20 backport runs the old code with no safety check at all. Wiz's testing found that @v4 (resolving to v4.4.x) and @v4.4.0 were protected, while @v4.3.0, or a SHA pinned to that release, was not.
Plenty of routes still go around checkout
Anything that fetches code without actions/checkout is unrestricted, Wiz notes. That includes a plain git clone, gh pr checkout, gh repo clone, and third-party checkout actions pointed at a pull request's head ref. Other gaps the report lists:
- Other privileged triggers. The checkout protection covers only pull_request_target and workflow_run, so bot-command workflows on issue_comment (/deploy, /test) and repository_dispatch remain exploitable, even with checkout v7.
- Script injection. Interpolating a value such as a pull request's title into a shell step with ${{ }} lets an attacker run commands with no checkout at all. None of the 2026 changes touch this.
- Artifact poisoning. An unprivileged pull_request build can upload attacker-controlled output that a privileged workflow_run job then downloads and executes.
- The explicit opt-out. The allow-unsafe-pr-checkout flag reopens the original vector.
The research is the latest part of a Wiz series on GitHub Actions. It lands a day after other Wiz researchers described an automated campaign planting secret-dumping workflows with stolen GitHub tokens, and follows a real pwn request attack that seeded npm backdoors earlier this year.
Audit now, then write an event policy before December 2
Wiz recommends auditing workflows with an open-source scanner such as zizmor, or with simple grep searches for risky triggers, unsafe checkouts and event data used in expressions. Its specific advice:
- Bump any SHA-pinned actions/checkout to a commit at or above v2.8.0, v3.7.0, v4.4.0, v5.1.0, v6.1.0 or v7.0.0.
- Pass untrusted event data to shell steps through quoted environment variables, never through ${{ }} interpolation.
- Never execute artifacts produced by a pull request run, and use ephemeral runners for anything untrusted events can trigger.
- Use GitHub's policy insights to see which pull_request_target runs would be blocked, move what you can to pull_request, and allow pull_request_target only for specific, audited workflow files.
The December default will stop the trivial fork-and-PR attack in public repositories. The workflows still running pull_request_target afterwards will be the ones that deliberately opted in to handling untrusted input with privileges, and those are exactly the ones worth reading line by line.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.