GitHub Actions to Block pull_request_target by Default
GitHub has announced that starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories unless explicitly permitted by an applicable Actions event policy.
Radwan AbdulhadiEditor and technology writer
Overview of the Default Block
Starting December 2, 2026, GitHub Actions will block pull_request_target events by default across all public repositories, unless an applicable Actions event policy explicitly allows them. This enforcement date was previously scheduled for an earlier timeline. Further details are available from GitHub Changelog in the original source material.
The platform introduced this default rule through workflow execution protections. Initially, the rule runs in evaluate mode, allowing developers to see which workflow runs it would block before the actual enforcement begins. It is important to note that private and internal repositories are not affected by this change.
Security Risks and Rationale
The pull_request_target trigger runs in the context of the base repository and has access to its sensitive secrets. If a workflow executes untrusted code originating from a fork, that untrusted code could potentially compromise your pipeline or steal secrets. The new default rule helps reduce this inherent security risk while still letting maintainers explicitly allow workflows that legitimately depend on the trigger.
This security update applies specifically to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud, but it does not affect GitHub Enterprise Server installations.
Brownouts and Evaluation Windows
Before permanent enforcement takes effect on December 2, 2026, GitHub will temporarily enforce the default protection during two scheduled brownout windows. These windows are designed to help maintainers identify affected workflows and update their policies prior to permanent enforcement.
During each brownout window, any pull_request_target workflow attempts blocked by the default rule in affected public repositories will generate failed runs accompanied by an error annotation, meaning the workflows will not execute. Following each window, the default rule returns to evaluate mode, letting workflows run with warnings.
Action Items for Developers
Before the first scheduled brownout on November 9, developers can use Insights to review which workflow runs the rule would block. From that point, teams have two primary options: keep the default rule in place to block pull_request_target, or explicitly allow pull_request_target in an applicable Actions event policy if their workflows depend heavily on it.
Teams can also utilize workflow file targeting to allow specific workflows securely. Detailed configuration instructions are available on how to control workflow execution to properly configure repository policies.
Sources
- GitHub Changelogpull_request_target blocked by default December 2
Continue chronologically
Related entity coverage
Related stories
GitHub Actions API and UI Updates Query Count Results
GitHub has introduced updates to query results in the GitHub Actions API and UI to improve performance and provide more accurate record counts.
GitHub Code Coverage Updates CI Uploads for New Branches
GitHub updates its Code Quality upload-code-coverage action so code coverage uploads no longer fail CI for new branches without open pull requests.
GitHub Adds REST API Control for Code Coverage Rules
GitHub now lets teams manage the Restrict code coverage repository ruleset through its generally available REST API.
GitHub makes Actions workflow protections generally available
GitHub has moved Actions workflow execution protections to general availability, adding file-level policies, insights and REST API management.
