GitHub blocks pull_request_target by default on December 2: brownouts Nov 9 and 16

GitHub will start blocking the pull_request_target workflow trigger by default in public repositories on December 2, 2026, a month later than first scheduled, and will test the block with two two-hour "brownouts" on November 9 and November 16. If a public repository of yours runs labelers, preview deploys, or fork CI on that trigger without an explicit Actions event policy, those runs will fail once enforcement starts. The change matters beyond GitHub housekeeping: pull_request_target has been one of the most exploited weaknesses in CI pipelines, and this is GitHub's biggest step yet to switch it off by default.

Key points

• From December 2, 2026, GitHub Actions blocks pull_request_target events in public repositories unless an applicable Actions event policy explicitly allows them (GitHub changelog, November 2, 2026).
• Enforcement was previously scheduled for November 2, 2026; GitHub moved it to December 2 (changelog editor's note dated October 21, 2026).
• Two brownouts will enforce the block temporarily: November 9 and November 16, 2026, both 16:00 to 18:00 UTC. Affected runs fail with an error annotation and the workflow does not execute.
• Private and internal repositories are not affected, and the change does not apply to GitHub Enterprise Server. It covers public repositories on GitHub Free, Team and Enterprise Cloud.
• Until enforcement, the rule runs in evaluate mode: workflows keep running, and the Insights view shows which runs would have been blocked.

What to do

1. Find out if you are affected. Search your public repositories' .github/workflows for pull_request_target. Then open Actions policy Insights, which lists the workflow runs the default rule would block. GitHub tells you to do this before the first brownout on November 9.
2. Decide per workflow. If it does not need repository secrets or a write token, switch it to the pull_request event, which runs with a read-only token and no secrets for fork pull requests. If it truly needs the trigger (a bot that labels or comments on fork PRs, for example), add or update an Actions event policy that allows pull_request_target, and use workflow file targeting to allow only the specific workflow files that need it.
3. If you keep the trigger, audit it. GitHub's documentation is explicit that such a workflow should not check out, build, or run code from an untrusted pull request while it has access to secrets or a privileged GITHUB_TOKEN.
4. Plan for the brownouts. On November 9 and 16, between 16:00 and 18:00 UTC, expect failed runs for anything the default rule would block. Treat them as a free dry run, and avoid scheduling releases that depend on these workflows in those windows.
5. Do nothing if you want the block. Leaving the default rule in place is a supported choice: after enforcement, GitHub simply blocks the event.

What happened

On November 2, 2026, GitHub published a changelog entry titled "pull_request_target blocked by default December 2". It says that starting December 2, GitHub Actions will block pull_request_target events by default in all public repositories, unless an applicable Actions event policy explicitly allows them, and that enforcement "was previously scheduled for November 2, 2026".

The block is not a new feature on its own. It is the default rule of GitHub's workflow execution protections, which reached general availability on September 17, 2026. Those protections let an enterprise, organization or repository define an allowlist that controls who can trigger a workflow (actor rules) and what events can start it (event rules). General availability added workflow file targeting, so a rule can apply to specific workflow files instead of a whole repository; an Insights view that shows how rules are evaluated and enforced; and a REST API for managing the rules as code.

For public repositories without an applicable event policy, GitHub added a default rule that disables pull_request_target. It has been running in evaluate mode, so runs were not blocked, but GitHub recorded which ones would have been.

One wording difference is worth knowing about. The September 17 announcement says GitHub would enforce the default for "affected repositories that were using the default pull_request_target policy before general availability". The November 2 notice describes the block as applying to all public repositories unless a policy allows the event. GitHub's documentation page on the topic repeats the narrower phrasing. We could not find a clarification of whether the two describe the same set of repositories, so the safe reading for maintainers is to assume any public repository without its own event policy could be affected.

Background

pull_request_target was added so that workflows can react to pull requests from forks with more trust than the ordinary pull_request event. By design, it runs the workflow file from the base repository's default branch, with the base repository's GITHUB_TOKEN and access to its secrets. GitHub's documentation says that on its own this is safe, because "only trusted code from the default branch runs".

The danger comes when a workflow author overrides that. A common mistake is to point actions/checkout at the pull request's head commit and then run something from it, such as make test. The attacker only needs a fork whose Makefile, build script or dependency file contains malicious commands, and those commands then run with the base repository's secrets. The pattern is known as a "pwn request", and GitHub's documentation says it has been the root cause of multiple supply-chain compromises.

GitHub has been tightening this for a year:

• On December 8, 2025, pull_request_target began always taking its workflow file and checkout commit from the default branch, which stopped outdated workflows on other branches from being run.
• According to the security firm Wiz's 2026 timeline, actions/checkout v7.0.0 (June 18, 2026) began blocking fork-code checkouts in untrusted triggers by default, read-only cache tokens followed on June 26, and the checkout protections were backported to older major versions on July 20.
• Workflow execution protections reached general availability on September 17, 2026, with the default pull_request_target rule in evaluate mode.

How the rollout works

Date (2026)	What happens
September 17	Workflow execution protections generally available; default rule in evaluate mode
October 21	Enforcement date moved to December 2 (editor's note)
November 9, 16:00 to 18:00 UTC	First brownout: blocked runs fail with an error annotation
November 16, 16:00 to 18:00 UTC	Second brownout
December 2	Permanent enforcement of the default rule

First brownout (Nov 9)7

Second brownout (Nov 16)14

Enforcement (Dec 2)30

Days until each step from the November 2 notice (days)

	days
First brownout (Nov 9)	7
Second brownout (Nov 16)	14
Enforcement (Dec 2)	30

Source: GitHub changelog, November 2, 2026

After each brownout the rule returns to evaluate mode, so workflows run again with warnings. The brownout windows only matter for public repositories where the default rule applies.

What it means

For maintainers of open-source projects. The default flips from "allowed unless you restrict it" to "blocked unless you allow it" for the riskiest trigger. Projects that rely on labelers, triage bots, or automatic previews for fork PRs have a clear to-do list: audit, then either migrate or allow-list narrowly with workflow file targeting.

For attackers and defenders. Wiz argues that the changes make the default-case exploit significantly harder but do not remove the vulnerability class; they shift it. Its analysis points out that December 2 "is a default, not a ban": maintainers who depend on the trigger will add an allow policy, and those are exactly the workflows that handle untrusted input with elevated privileges. Wiz also notes that the default policy does not cover private and internal repositories, nor workflow_run.

Wiz adds a caution about hardening advice. GitHub's checkout protections live inside actions/checkout itself, so a workflow pinned by commit SHA to a release older than the patched versions (v2.8.0, v3.7.0, v4.4.0, v5.1.0, v6.1.0 or v7.0.0 and later, per Wiz) does not get them. Workflows that fetch fork code with git clone or gh pr checkout instead of actions/checkout also bypass them. GitHub's own documentation makes a related point: pwn requests are not unique to pull_request_target, and any event that runs with secrets, such as issue_comment or workflow_run, becomes vulnerable if it fetches and runs untrusted pull request code.

For everyone else. Private repositories and GitHub Enterprise Server are untouched, so large internal pipelines will not see failures from this change.

What we don't know yet

• Whether the enforcement set is exactly "repositories that used the default policy before general availability" (September 17 wording) or every public repository without a policy (November 2 wording). GitHub has not reconciled the two in the pages we read.
• How many public repositories will see blocked runs. GitHub has not published a figure, and we have not seen one from other sources.
• Whether GitHub will move the date again. It has done so once already, from November 2 to December 2.

What to watch next

• November 9 and November 16, 16:00 to 18:00 UTC: the brownouts. Failed runs with an error annotation in those windows mean a workflow needs a decision.
• December 2: permanent enforcement.
• Updates to GitHub's "Securely using pull_request_target" documentation, which carries the current policy text, and to the changelog entry itself.

Sources

• GitHub Changelog: pull_request_target blocked by default December 2 (November 2, 2026)
• GitHub Changelog: Workflow execution protections in GitHub Actions generally available (September 17, 2026)
• GitHub Docs: Securely using pull_request_target
• GitHub Changelog: Actions pull_request_target and environment branch protections changes (November 7, 2025)
• Wiz: GitHub Actions Security, Auditing pull_request_target