GitHub Actions Will Block a Privileged Pull Request Trigger by Default on December 2
GitHub has moved the enforcement date for a GitHub Actions security change, according to its November 2 announcement. Starting December 2, 2026, pull_request_target events will be blocked by default in public repositories unless an applicable Actions event policy explicitly permits them. The original enforcement date was November 2. GitHub says the new default is currently in evaluate mode, allowing maintainers to see which runs would be affected before enforcement begins.
This does not mean every GitHub Actions workflow will stop working. It specifically concerns the pull_request_target event and applies to public repositories on GitHub Free, Team and Enterprise Cloud, not private or internal repositories and not GitHub Enterprise Server. GitHub’s November 2 changelog is the primary source.
Why GitHub is tightening the default
The pull_request_target event runs in the security context of the repository receiving a pull request, rather than the untrusted code’s fork. That design is useful for carefully controlled maintenance workflows, but it can become dangerous if a workflow checks out and executes untrusted contributions while having privileged access to secrets or a writable token.
The new setting is not a replacement for a secure workflow design. A repository owner who deliberately permits pull_request_target must still review what permissions the job receives and whether it executes material controlled by an untrusted contributor.
Two brownouts come before the December 2 deadline
GitHub has scheduled two temporary enforcement windows, both in UTC:
| Date | Brownout window (UTC) | What to expect |
|---|---|---|
| November 9, 2026 | 16:00 to 18:00 | Affected runs will be blocked and marked failed with an error annotation |
| November 16, 2026 | 16:00 to 18:00 | The same temporary default enforcement applies |
| December 2, 2026 | Permanent enforcement begins | Public repository runs are blocked by default unless explicitly allowed |
Outside the temporary windows before December 2, GitHub says the default rule returns to evaluate mode, allowing runs to continue with warnings. A failed run during a brownout does not necessarily indicate that the repository’s tests, build scripts or application code are broken; inspect the GitHub Actions annotation first.
Review affected workflows before November 9
Search the .github/workflows/ directory in public repositories for uses of pull_request_target. For each match, check whether the trigger is necessary, whether the job has access to secrets or write permissions, and whether any untrusted pull request content is executed. Simply switching to another trigger without considering the workflow’s permission model can introduce a different problem.
GitHub recommends reviewing Insights to identify workflow runs that would be blocked. Teams can then keep the safer default or define an explicit Actions event policy. GitHub says workflow-file targeting can limit exceptions to specific workflows. Consult the official workflow execution controls documentation for current options, and confirm policy behavior against your repository’s actual settings.
If your repository deploys a web app or API, also separate untrusted pull request validation from privileged publishing. A successful build should not automatically give untrusted code access to production credentials. The Web2Generators Mermaid API sequence diagram guide can help visualize which events trigger tests, review, deployments and API calls. Use the free Mermaid live editor to draft your own flow.