GitHub First pull_request_target Brownout Is Today. Here Is What Breaks

The pull_request_target block starts with a rehearsal today

GitHub first brownout for the pull_request_target block runs today, Monday November 9, 2026, from 16:00 to 18:00 UTC. For two hours, affected workflows in public repositories will fail with an error annotation and will not execute. Then the rule switches back to evaluate mode, where workflows run with warnings. A second brownout follows on November 16. The permanent block starts December 2.

GitHub announced the change on November 2, 2026, and at the same time pushed enforcement back a month, from November 2 to December 2. The delay is the good news: the rule currently runs in evaluate mode, which means GitHub logs which workflow runs it would block without blocking them. You can see those would-be blocks in your repository Insights tab before anything breaks. The brownouts are the rehearsal, and today is the first chance to find out whether your projects are affected.

Why pull_request_target is dangerous

The pull_request_target trigger runs in the base repository context, with access to its secrets and a write token, so maintainers can run bots that label, comment on, or triage pull requests from forks. That is the legitimate use, and it is fine. The danger appears when a workflow combines that privileged context with untrusted code.

The classic mistake is checking out the pull request head and then building or testing it. At that point, code written by a stranger is running with your repository secrets. GitHub docs show that pattern as an insecure example for a reason: it is the single most common way open-source CI gets compromised. An attacker opens a pull request containing a workflow change or a malicious test script, the privileged workflow runs it, and secrets leak. The trigger itself is not the vulnerability. Checking out and executing fork code under it is.

Who is affected, and who is not

The block applies to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud. Private and internal repositories are not affected, and neither is GitHub Enterprise Server. If your project is private, you can stop reading. If it is public and uses pull_request_target anywhere, today brownout is your test.

The scale is larger than most maintainers expect. One audit of 202 workflows across 5 major public repositories found 27 using the trigger, though after manual review none of them executed fork code. The point is that the trigger is widespread, and many maintainers do not know it is there, because it was added years ago for a bot that nobody remembers installing.

What to do before the brownout ends

Open your repository Settings, then Actions, then Policies, and look at Policy insights. GitHub says to use Insights before November 9 to see which runs the rule would block, and today window is the live version of that check. If a workflow appears in the report, read it. The audit target is specific: any checkout step that pulls the fork head, any ref pointing at refs/pull head or merge, and any allow-unsafe-pr-checkout opt-out, which disables the checkout protection shipped in actions/checkout v7.

Then make a decision for each workflow. If you do not need the trigger, let the rule block it on December 2. If you do need it, allow it explicitly in an Actions event policy, and use workflow file targeting so only the workflows that need it get it, rather than allowing the trigger in general. If your open-source project has a bot that labels or comments on pull requests, today at 16:00 UTC is when you find out which trigger it uses.

The December 2 deadline is close enough to matter and far enough to fix properly. Check Insights today, fix what needs fixing, and use the November 16 brownout as the confirmation run. That is the whole job, and it is a lot cheaper than explaining a leaked secret in January. For teams already deep in GitHub Copilot code review, the same audit applies: agent workflows that touch pull requests deserve the same scrutiny as the bots they replaced.