By ByteBot
GitHub’s workflow execution protections are now generally available, and they come with a hard date attached: November 2, 2026. That’s when GitHub will automatically block pull_request_target events in any public repository that hasn’t configured an Actions policy. You have six weeks. If your CI pipelines use that trigger — and a lot of automation does — this is not a read-it-later story.
What Workflow Execution Protections Do
The feature, available since September 17, adds a policy layer on top of your GitHub Actions configuration. It has two rule types: actor rules (who can trigger a workflow) and event rules (which events are permitted to start one). The idea is to separate who writes code from who runs CI — you can give a contributor write access without automatically letting them kick off your deployment pipeline.
New in the GA release: workflow file targeting, which lets you apply different policies to different workflow files within the same repository. Restrict deploy.yml to your ops team while leaving CI workflows open to all contributors. There’s also a REST API for managing policies at scale and an evaluate mode that shows you exactly which workflow runs would be blocked — without actually blocking them. Use evaluate mode first. Always.
Why pull_request_target Is the Problem
The November 2 default isn’t arbitrary. pull_request_target is the most consistently exploited event trigger in GitHub Actions, and it’s been a target for good reason: it runs with the base repository’s token and secrets, even when it checks out code from an untrusted fork. That means an attacker who can get a pull request merged — or who can find a misconfigured workflow — can run arbitrary code with access to your production secrets.
The Trivy supply chain attack in March 2026 made this concrete. A misconfigured pull_request_target workflow allowed attackers to steal a privileged personal access token from Aqua Security. They then force-pushed malicious code to 75 of 76 Trivy version tags, silently harvesting CI/CD secrets from over 10,000 affected workflows — because the legitimate Trivy scan still ran. The 2025 tj-actions/changed-files compromise hit 23,000+ repositories through the same attack surface. These are not edge cases; they’re the natural outcome of a trigger designed for convenience rather than isolation.
Who Needs to Act Before November 2
Public repositories are GitHub’s initial enforcement target, so start there. The most exposed setups are:
- Open-source projects accepting fork pull requests — if you have any
pull_request_targetworkflows, audit them now - Repos with AI code-review bots or auto-labelers — these typically use
pull_request_targetto read fork content while holding write tokens, and they’re exactly what enforcement will block - Anything that runs Dependabot-triggered workflows — Dependabot must be explicitly added as an allowed actor, or its workflow triggers will fail after November 2
Private repositories aren’t in the November 2 enforcement scope, but that’s no reason to skip the audit. The vulnerability is the same regardless of visibility.
What to Do Now
First, enable evaluate mode for your organization. It’s in GitHub Actions settings under Policies. Create a ruleset, add an event rule blocking pull_request_target, and run in evaluate mode for a week. The insights dashboard will surface every workflow that would have been blocked. That’s your actual exposure list.
For workflows that legitimately need pull_request_target behavior — posting review comments, updating PR status — the standard fix is to split the workflow into two:
- Workflow A uses
on: pull_request— read-only, no secrets, runs the untrusted analysis and saves results as artifacts - Workflow B uses
on: workflow_run— fires after Workflow A, holds write tokens and secrets, reads the saved artifacts and posts comments
This pattern keeps untrusted code execution isolated from anything privileged. It’s more setup than a single workflow, but it’s the architecture that GitHub’s own 2026 security roadmap is built around. If splitting isn’t practical, use workflow file targeting to explicitly allow pull_request_target on specific files while blocking it everywhere else.
The Bigger Picture
Workflow execution protections are one piece of GitHub’s broader CI/CD security push for 2026. Also in the pipeline: workflow-level dependency locking (like Go’s go.sum, but for Actions), scoped secrets that won’t be accessible to anyone with repo write access by default, and a native egress firewall for GitHub-hosted runners. The direction is clear — treating CI pipelines as security infrastructure, not just automation scripts.
The November 2 deadline is aggressive, but six weeks is workable if you start with evaluate mode today rather than waiting for the enforcement notice. GitHub is giving you the tools to understand your exposure before it blocks anything. Use them. The teams that get hit by supply chain attacks are the ones who knew the risk and decided to deal with it later.
