Continuous integration is one of the most privileged systems a SaaS company runs. It holds deploy credentials, signs artifacts, and touches production. In September 2026, GitHub shipped two changes every team on Actions should act on. On September 17, workflow execution protections became generally available: allowlists that control who can trigger a workflow and which events can start it. On September 23, GitHub confirmed Node 20 is no longer available on Actions runners; JavaScript actions now run on Node 24, and the temporary opt-out is gone. Neither change is glamorous. Both decide whether your pipeline is something an attacker, or a stale dependency, can quietly break.
What execution protections do
Execution protections let you define rules evaluated before a run starts. Actor rules cover who can trigger a workflow; event rules cover what can start it. General availability added workflow file targeting, so one repository can apply different policies to different workflows, for example restricting deploy.yml to a designated team while CI stays open to all contributors. GitHub also added Insights to see how rules are evaluated and enforced, and a REST API to manage rules at enterprise, organization, and repository level, which makes Actions policy something you can keep in code.
Why pull_request_target is the headline
GitHub calls vulnerabilities in pull_request_target workflows, such as Pwn Requests, one of the most commonly exploited weaknesses in Actions. The trigger runs with access to your secrets in the context of the base repository, so if a workflow checks out and executes code from a fork, untrusted code can poison the pipeline and exfiltrate secrets. For public repositories without an applicable event policy, GitHub is introducing a default rule that disables pull_request_target . It starts in evaluate mode, and on November 2, 2026, GitHub will enforce it for affected repositories that were using the default policy before general availability.
Private repos are not exempt from the lesson
The default rule does not apply to private or internal repositories. That does not make them safe. Contractors, compromised accounts, and automation bots can still trigger workflows with more privilege than they need. Use the GA features to restrict who can run deployment and release workflows in private repos too, and to limit events such as manual dispatch on sensitive pipelines to named teams. The same rule set, managed through the API, can apply consistently across every repository you own.
# Safer pattern: untrusted PR code never sees secrets
on:
pull_request: # runs fork code WITHOUT secrets
branches: [main]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: npm ci && npm test
# Privileged follow-up (labels, comments) runs separately and
# never checks out or executes the PR's code.Use evaluate mode before you enforce
Evaluate mode carries over from the preview: rules run in shadow mode and show which workflow runs would have been blocked. Turn rules on in evaluate mode, review Insights for a week or two, and talk to the owners of anything that would break. For public repositories affected by the November 2 default, the choice is simple: leave the rule in place, or explicitly allow pull_request_target for the specific workflows that genuinely need it, using workflow file targeting. Do not blanket-allow it to make the warning go away.
Node 24 is now the runtime for JavaScript actions
With Node 20 removed, JavaScript actions run on Node 24. If you maintain internal actions, update runs.using to node24 and publish a new release. If you consume third-party actions, update to versions that support Node 24; GitHub says its first-party actions already do. Self-hosted runners need attention too: GitHub notes that Node 24 is incompatible with macOS 13.4 and earlier and does not officially support ARM32, so runners on those platforms are no longer supported. Audit your runner fleet rather than discovering this during a release.
Least privilege still matters most
Execution protections decide who can start a run. They do not shrink what a run can do once it starts. Set default workflow permissions to read-only, grant write scopes per job, use short-lived cloud credentials through OIDC instead of stored keys, and protect production environments with required reviewers. Pin third-party actions to full commit SHAs for sensitive workflows. If something malicious does execute, it should find little worth stealing.
If you maintain open-source libraries alongside your product, start with those public repositories, because they are the ones the November 2 default will touch first and the ones where forks from strangers are routine.
Manage rules as code across repositories
The new REST API means Actions policy can live in a repository like any other infrastructure. Keep a small configuration file describing actor and event rules per workflow pattern, apply it with a scheduled job, and review changes through pull requests. That gives you an audit trail of who changed CI trust boundaries and when, which is exactly the evidence security reviewers ask for. It also prevents the slow drift that happens when rules are edited by hand in dozens of repositories.
A two-week rollout plan
Week one: inventory workflows that use pull_request_target , workflow_dispatch , or deploy credentials; enable execution protections in evaluate mode; update internal actions to Node 24. Week two: review Insights, fix or explicitly allow the workflows that need privileged triggers, enforce rules for deploy and release workflows, and confirm self-hosted runners run supported operating systems. Then schedule a quarterly review.
Founder takeaway
Your CI pipeline is a production system. Before November 2, review every pull_request_target workflow, adopt execution protections with workflow file targeting for deploy and release pipelines, run rules in evaluate mode before enforcing them, finish the move to Node 24 actions and supported runners, and keep permissions minimal. It is a short project that closes one of the most common ways SaaS companies leak secrets.
