GitHub to Block pull_request_target Workflows by Default Starting December 2

GitHub will begin blocking GitHub Actions workflows triggered by pull_request_target in public repositories on December 2, 2026, expanding its protections against a class of CI/CD vulnerabilities that has repeatedly enabled attackers to steal credentials and compromise open source software releases.

The restriction, originally announced in September, will prevent affected workflows from running unless an applicable Actions event policy explicitly allows them. GitHub had initially scheduled enforcement for November 2 but confirmed the postponed December 2 deadline in a new update this week, giving maintainers additional time to review their automation and configure exceptions.

The new restriction goes beyond protections introduced in June, when GitHub updated actions/checkout to prevent common attempts to check out untrusted pull request code inside privileged workflows. This time, GitHub is blocking the pull_request_target trigger itself by default, including for workflows that use it safely.

GitHub introduced pull_request_target in 2020 to help maintainers automate tasks involving pull requests from external contributors. Unlike the standard pull_request event, which restricts access to secrets and provides a read-only token for contributions from forks, pull_request_target runs in the context of the base repository with access to its configured secrets and token permissions.

That elevated access makes the trigger useful for legitimate maintenance tasks such as assigning reviewers, labeling pull requests, and posting authenticated comments. The workflow definition runs from the repository's trusted default branch, rather than the contributor's proposed changes.

The security risk emerges when that privileged workflow checks out and executes code from an untrusted fork or passes attacker-controlled pull request data into shell commands. A malicious contributor can exploit those mistakes to execute commands with access to credentials and other resources intended only for trusted automation.

Researchers have warned about these vulnerabilities, commonly called "pwn requests," since at least 2021. Variations of this attack pattern contributed to major supply chain incidents involving Nx, PostHog, and TanStack.

GitHub's June changes addressed a common source of these vulnerabilities by making actions/checkout reject unsafe fork checkouts in privileged workflows unless explicitly overridden. The December policy takes a broader approach, preventing the event from triggering a workflow at all unless administrators have authorized it through an applicable policy.

GitHub's default restriction currently operates in evaluation mode, allowing affected workflows to continue running before enforcement begins.

The company has scheduled two temporary enforcement periods, known as brownouts, to expose configurations that will stop working under the new policy:

• November 9, 16:00–18:00 UTC
• November 16, 16:00–18:00 UTC

During those windows, blocked pull_request_target attempts will generate failed workflow runs with an error annotation instead of executing. The default policy will return to evaluation mode after each test.

On December 2, the restriction becomes permanent for affected public repositories without an applicable policy allowing the event. The change applies to public repositories on GitHub Free, Team, and Enterprise Cloud, but excludes private and internal repositories and GitHub Enterprise Server.

Maintainers who still require pull_request_target can create an Actions event policy that explicitly permits it. GitHub supports targeting individual workflow files, allowing administrators to preserve specific automation without enabling the trigger across an entire repository. Existing applicable event policies are not replaced by the new default.

The broader restriction introduces complications for open source projects that have relied on pull_request_target for legitimate automation, sometimes across dozens of repositories.

A carefully configured workflow that only labels pull requests or manages project metadata may pose little of the risk GitHub is addressing, but it will still be subject to the new restriction. Maintainers must either allow these workflows explicitly or move them to another trigger where appropriate.

There are also differences in the administrative tools available across GitHub's pricing tiers.

GitHub's documentation for workflow execution protections describes policy configuration at the repository, organization, and enterprise levels for public repositories, including those on free plans. However, the ability to create policies in evaluation mode is reserved for Enterprise Cloud, where administrators can examine policy insights before turning on enforcement.

That disparity had already prompted questions following GitHub's September announcement of the new defaults.

In a GitHub Community discussion, open source maintainer George Joseph questioned how smaller organizations were expected to assess the impact without Enterprise policy insights.

"How would us mere mortals who run open-source organizations see what workflows would be affected?" he asked.

A community response suggested manually searching repositories for workflows using pull_request_target, inspecting existing workflow runs, and testing explicit allowlisting policies. These approaches can identify affected configurations, but require additional work from maintainers managing multiple repositories.

The December deadline gives projects several more weeks to prepare, while the scheduled brownouts offer a preview of what enforcement will look like. GitHub's decision also represents a significant shift for a feature originally created to make external contributions easier to manage: privileged pull request automation will now require an explicit exception to continue running under the new default.