GitHub sets December 2 default block for privileged pull request workflows

GitHub moved its default restriction for privileged pull request workflows to December 2 and announced two brownouts.

GitHub Actions will block the `pull_request_target` event by default in public repositories starting December 2, 2026, unless an applicable Actions event policy allows it. GitHub’s November 2 notice moved enforcement from the previously scheduled November 2 date. It applies to public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories and GitHub Enterprise Server are outside the announced change. [GitHub announcement](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/)

Why this event needs different treatment

GitHub Actions can respond to pull requests from contributors whose branches live in forks. Which event starts a workflow affects the context in which its jobs run. GitHub says `pull_request_target` runs in the context of the base repository and can access its secrets. That lets a workflow perform operations on the receiving repository, but creates a trust boundary if that same workflow executes code controlled by the contributor. In that situation, a contributor’s change could run inside a job with access the contributor would not otherwise have. [GitHub announcement](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/)

Consider a workflow that adds a label or posts a comment on a new pull request. The job can often make that decision from event metadata. A different workflow might need to build and test the proposed source tree. If a job checks out and executes the contributor's code while holding write access or secrets, that code can run with access the contributor would not otherwise have. A maintainer reviewing the event can use that distinction to decide which steps require base-repository access and which ones can run with the permissions appropriate for untrusted contributions.

What maintainers will see before December 2

The rule first operates in evaluate mode. GitHub says Actions Insights can show runs the rule would block, which gives maintainers a starting point for finding workflows that depend on the event. There are two two-hour enforcement windows before the permanent change. They run on November 9 and November 16 from 16:00 to 18:00 UTC, or 9:30 to 11:30 p.m. IST. During each window, affected attempts create failed runs with an annotation and the workflow does not execute. After each window, GitHub says the rule returns to evaluate mode, where affected workflows run with warnings. [GitHub schedule and preparation guidance](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/)

GitHub’s preparation options are to keep the default block or allow the event through an applicable policy when a workflow needs it. A policy can target individual workflow files. For a repository that intentionally relies on this event, file-level targeting helps the maintainer document the exception alongside a concrete job and verify what that job executes. A repository-wide exception is harder to evaluate because new workflows could inherit access without a separate decision about why they need it. [GitHub announcement](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/)

Teams can use the announced windows as a way to test whether expected labels, comments and other pull request automation still appear. The test should exercise a pull request from a fork, since a change submitted from inside the repository does not exercise the same boundary. The date shift gives maintainers time to identify the affected jobs and verify what they can still do before the new default takes effect.