GitHub Actions to Block pull_request_target by Default December 2

What Changes on December 2

On November 2, GitHub announced that Actions will block the pull_request_target event by default in public repositories unless an applicable Actions event policy explicitly permits it. The permanent enforcement date is December 2, 2026; GitHub had previously planned to turn the protection on November 2.

The rule currently runs in evaluate mode, which lets maintainers inspect warnings and policy insights without immediately stopping affected workflows. This is a planned behavior change, not evidence that every repository is already blocked today.

The Two Brownout Windows

GitHub has scheduled two temporary enforcement windows: November 9, 2026, from 16:00 to 18:00 UTC, and November 16, 2026, from 16:00 to 18:00 UTC. During each brownout, affected pull_request_target runs can fail with an annotation instead of executing. The rule returns to evaluate mode after the window.

For maintainers, these short windows are a rehearsal. A failure during the brownout may reveal automation that would stop after December 2. It does not necessarily mean a code bug in the repository.

Who Is Affected — and Who Is Not

According to GitHub, the new default applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. It does not apply to private or internal repositories or GitHub Enterprise Server. Existing applicable event policies also matter: an explicit allow rule can change how the event is handled.

There is no basis for saying that all GitHub Actions jobs are blocked. The subject is the pull_request_target trigger in the affected public-repository policy context, not ordinary push or pull_request automation.

Why This Event Is Sensitive

A pull_request_target workflow runs in the base repository context and can access its GITHUB_TOKEN and secrets. Used carefully, this lets trusted automation label or triage pull requests. Risk appears when the workflow then fetches and executes untrusted code supplied by a fork while retaining that privileged context.

The GitHub security guide highlights this risk and distinguishes it from a pull_request workflow, where permissions and access to secrets are more constrained for untrusted fork contributions. Switching event types is not a mechanical one-line fix: teams must confirm what their automation actually needs.

What Maintainers Should Check Now

Audit workflow files for on: pull_request_target and review the policies applying at repository, organization and enterprise scope. Use GitHub Actions policy insights to find would-be blocked executions while evaluate mode is active.

If the workflow does not require privileged access, assess whether a pull_request-based approach is suitable. If the trigger is genuinely required, create a narrowly scoped explicit event policy only after reviewing the security model. GitHub documents workflow-file targeting for limiting exceptions.

Do not solve a broken workflow by granting broad secrets access to fork code. Independently check checkout ref, executed scripts, dependencies, artifacts and token permissions before making any exception.

Why It Matters

Open-source maintainers can experience failed security or triage automation even when their application code is healthy. The impact is operational: missed labels, approval tasks or automated checks could go unnoticed during a short brownout if teams do not monitor Actions failures.

For software buyers evaluating development platforms, this highlights an often-overlooked cost: governance changes can require workflow maintenance. A platform security improvement can still have migration work attached.

Our Take

Treat November 9 as the practical audit deadline rather than waiting for December 2. Review the affected jobs, make narrowly justified changes, and keep a record of which workflows need privileged triggers. Avoid treating every exception as equally safe.

This analysis is based on GitHub’s dated release note and documentation. DigiOffly has not executed affected workflows or measured brownout behavior in a live repository.