GitHub will restrict pull_request_target by default on affected public repos on November 2, 2026

The first thing that breaks in a Monday rollout is the bot. GitHub's documentation says bots such as dependabot[bot] have to be added as allowed actors when workflows depend on them ^[13]. An allowlist built from a roster of humans quietly stops the dependency updates nobody on the team thought of as a trigger.

The dated part is pull_request_target. That trigger runs with the base repository's token and secrets, and a workflow that checks out code from an untrusted fork can run the attacker's code with those privileges ^[15]. GitHub tightened actions/checkout in June ^[16]. The devops.com account says the workflows to look at first are the ones using pull_request_target that check out untrusted code while holding secrets or write permissions ^[17].

Evaluate mode is how you find out what an allowlist would stop. GitHub's June announcement described it as a way to "run your rules in shadow, so you can see exactly what a rule would block before you enforce it" ^[10]. The protections themselves reach further than the shadow test does: all public repositories, plus private repositories on GitHub Team or GitHub Enterprise ^[12].

Actor rules unbundle two permissions that arrived together from the day Actions launched, when write access to a repository was enough to start a workflow run ^[23]. GitHub's documentation puts the point this way: "Actor rules let you separate who contributes code from who runs your CI, so you can grant a contributor write access without granting them the ability to execute workflows" ^[21]. Rules live under Settings, then Actions, then Policies, and build on GitHub's rulesets ^[22].

Mitch Ashley, vice president and practice lead at The Futurum Group, told devops.com that "a single compromised developer account can mean the difference between a well-running pipeline and compromised software" ^[19], and that "with these improvements, dev teams will no longer have to rely upon bespoke built solutions to secure this aspect of their development pipelines" ^[20]. GitHub's own 2026 Actions security roadmap points to incidents involving tj-actions/changed-files, Nx and trivy-action ^[18].

The preview ran 91 days, June 18 to September 17 ^[3]. GA added rules that target a single workflow file, insights into how rules are evaluated at enterprise, organization and repository level, and a REST API that creates, reads, updates and deletes policies at all three ^[7][8][9]. The API is the part that matters for anyone who already keeps branch protections in version control. The policy then goes through the same review as the code it governs.

Before November 2, check each workflow for two things. Does it hold secrets or write permissions, and does it check out code from a fork. Workflows answering yes to both are the ones the default restriction was written for ^[15][14]. The rest can be scoped one workflow file at a time ^[7].