GitHub pushes back its pull_request_target lockdown by a month
The default block on pull_request_target in public repos, due today, is delayed to 2 December. Two brownout windows will fail affected workflows early, on purpose.
GitHub has delayed its default block on pull_request_target in public repositories. Enforcement was due today, 2 November, but GitHub has pushed it back a month to 2 December.
The event is one of the most commonly exploited paths in GitHub Actions, because it runs with access to the base repository’s secrets even when triggered by a pull request from a fork. Untrusted code from that fork can end up running in a context that can read those secrets, a pattern known as a “pwn request”. From 2 December, public repositories on GitHub Free, Team and Enterprise Cloud without an explicit Actions event policy will have pull_request_target blocked by default. Private, internal and Enterprise Server repositories are unaffected.
Before that, GitHub is running two brownout windows, on 9 November and 16 November, where affected workflow runs will fail with error annotations before reverting to evaluate mode (warnings only, nothing blocked) in between.
Why it matters: if you maintain a public repository that uses pull_request_target, for example to label PRs or run checks that need secrets, you now have an extra month but should still use it. Check the policy insights GitHub provides to see which of your workflow runs would be blocked, and set an explicit Actions event policy before 2 December. Don’t ignore the 9 and 16 November brownouts: they’re designed to break things on purpose so you find out before enforcement is permanent.