GitHub Actions: pull_request_target Blocked by Default on December 2, First Test Brownouts This November 9
Starting December 2, 2026, GitHub will block the pull_request_target trigger by default across all public repositories. Ahead of the change, two two-hour test brownouts on November 9 and 16, from 4:00 PM to 6:00 PM UTC, will intentionally fail affected workflows.
If you maintain a public repository on GitHub that relies on the pull_request_target trigger, take note of the schedule: this Monday, November 9, from 4:00 PM to 6:00 PM UTC (5:00 PM to 7:00 PM Paris time), your workflows may fail. This is the first of two test brownouts announced by GitHub ahead of the default blocking of this trigger on December 2, 2026, across all public repositories (changelog).
Why This Trigger Is Being Targeted
pull_request_target is primarily used to automate reactions to pull requests originating from forks: labeling, triaging, commenting, and posting statuses. Its key distinction is that it runs in the context of the base repository, with access to its secrets and a write token. As long as the workflow only executes code from the default branch, it remains secure. However, if it checks out and executes code from the pull request, a malicious contributor can compromise the integration pipeline or exfiltrate secrets. That is the rationale highlighted by GitHub, whose documentation warns: a workflow triggered this way must never build or run untrusted pull request code with access to secrets.
The Timeline
- Until December 2: The default rule runs in evaluation mode, meaning workflows execute with warnings.
- November 9 and 16, 4:00 PM–6:00 PM UTC (5:00 PM–7:00 PM Paris time): Temporary brownouts. Affected workflows will generate failed runs with an error annotation.
- December 2: Permanent blocking by default, unless explicitly allowed. The original deadline was November 2.
This applies to public repositories on GitHub Free, Team, and Enterprise Cloud. Private and internal repositories, along with GitHub Enterprise Server, are unaffected.
What to Do Before Monday
GitHub advises checking Insights to identify runs that would be blocked. From there, maintainers face three options: if the workflow does not require secrets or write access, switch to the standard pull_request trigger; if it genuinely needs elevated privileges, allow it via an Actions event policy restricted strictly to that workflow file, ensuring it never executes pull request code; otherwise, let the block take effect.
Our take
pull_request_target is a well-known pitfall for maintainers, as the boundary between “reacting to a pull request” and “executing its code” is dangerously easy to cross unintentionally. Inverting the default behavior is the right move, and the brownouts help avoid surprises on launch day. The stakes are rising with AI coding agents opening pull requests at scale across public projects: the more automated contributions flow in, the more an overly permissive workflow becomes an attractive target. For maintainers, the remediation is quick but needs attention now: spending a few minutes in Insights will prevent an evening of failing CI builds.
Sources
- GitHub Changelog — pull_request_target blocked by default December 2 (November 2, 2026) Primary source
- GitHub Docs — Securely using pull_request_target Primary source
A primary source comes directly from the company, lab or organization concerned. A secondary source reports the information without being its author: we flag it as such. Spotted an error? See our corrections policy.
