GitHub pull_request_target Blocked by Default December 2: Who Is Affected, the November Brownouts and What to Check

GitHub will stop running pull_request_target workflows in public repositories by default on December 2, 2026, unless an Actions event policy explicitly allows them. If your company has code in a public GitHub repository, automation built on that trigger could stop working, and GitHub is testing the block in two short windows in November.

Private and internal repositories are not affected, so many companies will have nothing to change. The only way to know is to look, and the first test window is Monday, November 9.

What is changing with GitHub pull_request_target

GitHub Actions is the automation built into GitHub. It runs builds, tests and deployments when something happens in a repository. pull_request_target is a trigger that lets a workflow respond to pull requests, including those from outside forks, with elevated trust. GitHub's documentation says it runs the workflow from the base repository's default branch, with access to repository and organization secrets and a read/write GITHUB_TOKEN. Common uses are labeling, triage and posting authenticated status checks.

The timeline comes from GitHub's November 2 changelog and its September 17 announcement:

A brownout is a temporary trial of the block. During each window, affected workflow attempts create failed runs with an error annotation and do not execute. Afterward the rule returns to evaluate mode, where workflows run with warnings.

What is confirmed and what is not

Confirmed by GitHub: the December 2 date, both brownout windows, and the scope in the table below. An applicable Actions event policy can allow the trigger, and workflow file targeting can limit that allowance to specific workflows.

Claimed, without detail: GitHub's documentation describes the "pwn request" pattern, where a workflow with secrets checks out and runs code from a fork's pull request, and says it "has been the root cause of multiple supply-chain compromises." That page names no incidents and gives no counts.

Not known: the changelog does not say how many repositories are affected, gives no attack numbers and names no incident. It gives no time of day for enforcement on December 2. The date has moved once already, and nothing we read says whether it will move again, so plan around December 2.

Why GitHub is blocking pull_request_target workflows

GitHub's stated reason is conditional. The trigger runs in the context of the base repository and can reach its secrets, and in the changelog's words, "If a workflow executes untrusted code from a fork, that code could compromise your pipeline or steal secrets." A workflow that only labels a pull request is not the same risk as one that builds a stranger's code.

GitHub already moved against the worst version of this. On June 18, 2026, it announced that actions/checkout v7 refuses common pwn request patterns by default, with enforcement backported on July 20 to other supported major versions except v1. The December change goes further: it blocks the trigger itself unless a policy allows it.

Which GitHub repositories are affected

How to check your GitHub Actions workflows this week

For event policies you create yourself, GitHub's documentation points to a page called Policy insights, listed under the Actions policies page, and lists the Evaluate status for those policies as GitHub Enterprise Cloud only.

How to fix a pull_request_target workflow

GitHub's guidance comes down to using the trigger only when it is necessary:

• Use pull_request if the workflow does not need secrets. It runs with a read-only token and no other secrets.
• Split complex workflows so handling pull request code is separate from anything that touches secrets.
• Treat fork code as data only. Never build, test, install or otherwise run it in a privileged workflow.
• Limit secrets and GITHUB_TOKEN to the minimum permissions required.
• Treat artifacts from other workflows as untrusted, since they can originate from a fork.
• Use allow-unsafe-pr-checkout: true only after confirming the checked-out code is never executed.

Allowing the trigger in a policy keeps the workflow running. It does not make the workflow safe.

Why this matters for a company website or network

Public repositories are common outside software companies: marketing sites, documentation, client libraries and open source tools. The automation attached to them can hold deployment credentials or cloud keys, which is why a flaw in a build pipeline can reach well past the repository.

There are two risks here. One is operational: a labeling or status check workflow stops on December 2 and nobody knows why, because the person who built it has moved on. The other is the quick fix, where someone allows the trigger everywhere to make the error go away and leaves an unsafe workflow running.

Both come down to ownership. If nobody can say who is patching the software that runs your business, nobody is watching its build pipeline either. That applies double to apps built quickly with AI tools, where the automation may have been generated and never reviewed.

GitHub pull_request_target questions people are asking

Is GitHub blocking pull_request_target?

Yes, by default in public repositories on GitHub Free, Team and Enterprise Cloud, starting December 2, 2026, unless an applicable Actions event policy allows it.

Are private GitHub repositories affected?

No. Private and internal repositories are not affected, and neither is GitHub Enterprise Server.

What is a GitHub Actions brownout?

A temporary trial of the block. On November 9 and 16, from 16:00 to 18:00 UTC, affected workflows fail with an error annotation instead of running.

What is a pwn request?

GitHub uses the term for a workflow with secrets that checks out and runs code from a fork's pull request, which can let attacker code run with the workflow's privileges.

Should I just allow pull_request_target?

Only for specific workflows you have reviewed. Use workflow file targeting rather than allowing the trigger across a whole repository.

Does this stop all GitHub Actions supply chain attacks?

No. GitHub's documentation says the pwn request pattern can also occur in other event types, such as issue_comment and workflow_run, if they execute untrusted code.

The bigger lesson

Build pipelines hold some of the most powerful credentials a company has, and they tend to run unattended for years. A vendor changing a default is a useful prompt to find out what is running, who owns it and what it can reach.

For help reviewing your pipelines and the systems they touch, see our security hardening service or request a quote.

Get security alerts by email, with the free checklist.

Sources: GitHub Changelog, pull_request_target blocked by default December 2; GitHub Changelog, Workflow execution protections generally available; GitHub Changelog, Safer pull_request_target defaults for checkout; GitHub Docs, Securely using pull_request_target; GitHub Docs, Control workflow execution.