GitHub Actions November 2025: Ship the Fixes Now

GitHub Actions November 2025 is a rare triple‑whammy: a security‑driven change to pull_request_target on December 8, a macOS 13 runner shutdown with brownouts this month, and npm classic tokens getting revoked on November 19. If you run CI/CD for a product or a portfolio of repos, this is your cutover week. Below I’ll explain exactly what changed, why GitHub is doing it, and a step‑by‑step plan we’ve used to land these fixes fast—without breaking contributors or nightly builds. (github.blog)

What just changed—and when

Here’s the timeline that matters:

• December 8, 2025: GitHub changes how pull_request_target resolves workflow source and how environment branch protections are evaluated for PR events. The workflow and ref will always come from your repository’s default branch; environment rules evaluate against execution refs (default branch for pull_request_target, refs/pull/<number>/merge for pull_request). Expect policy mismatches if you filter by branch names today. (github.blog)
• Brownouts on Nov 11, 18, and 25 (14:00–00:00 UTC): Jobs using macos-13 (and its large/xlarge variants) will fail during these windows as a reminder to migrate. Final retirement is December 4, 2025. A new label, macos-15-intel, is available if you absolutely require Intel. (github.blog)
• November 19, 2025: npm classic tokens are permanently revoked. Granular tokens with write perms now enforce 2FA by default, introduce an optional CI Bypass 2FA flag, and cap lifetimes at 90 days (existing longer expiries adjusted to Feb 3, 2026). (github.blog)

There’s more in the background too: GitHub is moving the Actions runtime toward Node 24 and removing older toolchains from runner images (Node 18, Ruby 3.1, Android NDK 26, GCC 9/10) as of early November deployments. If your workflows rely on those versions implicitly, they’ll wobble. (github.blog)

Why GitHub is doing this (and why you should cheer)

Supply chain abuse is no longer hypothetical. Attacks have targeted GitHub Actions workflows and open source maintainers to steal tokens and secrets at scale. Media and researchers documented incidents like the “GhostAction” campaign, which injected malicious workflows to siphon PyPI, npm, AWS, and GitHub credentials. When defenders mapped the blast radius, they found hundreds of compromised accounts and thousands of leaked secrets across hundreds of repos. Locking down how PR events resolve refs, tightening environment rules, and hardening npm publishing are rational, overdue moves. (techradar.com)

On the npm side, classic long‑lived tokens plus weak 2FA flows have been a recurring root cause. GitHub’s November changes push teams toward short‑lived, scoped credentials and 2FA‑backed publishing (or fully automated Trusted Publishing via OIDC). That’s the right direction—even if it means a hectic week of pipeline surgery. (github.blog)

Upgrade Playbook: the fast, safe path through GitHub Actions November 2025

Here’s the exact order we use with client teams to ship these updates in a day or two.

1) Fix pull_request_target before December 8

The new behavior forces pull_request_target to load workflows and refs from your default branch. That’s good for security, but it breaks assumptions if you depended on base‑branch variations. It also changes how environments are evaluated, so branch filters that looked for feature/* won’t match anymore on PR events. Action: audit every workflow that uses pull_request_target, especially those exposing secrets to forks, and move as many as possible to pull_request with read‑only GITHUB_TOKEN and explicit permissions. (github.blog)

Practical guardrails that hold up in the real world:

• Prefer pull_request for fork validation. Reserve pull_request_target only for jobs that need elevated repo access or environment secrets.
• Harden permissions: set permissions: contents: read by default; grant narrow write scopes only where required.
• Gate sensitive jobs behind manual approvals, required checks, or on‑label triggers.
• Pin third‑party actions by SHA and keep them updated via Dependabot.
• Run CodeQL/code scanning on workflow files; it now flags common Actions vulnerabilities. (github.blog)

Context for skeptics: security advisories this year showed real‑world secret exfiltration via pull_request_target patterns. The new default‑branch source closes an entire class of “stale workflow on a base branch” pitfalls. Don’t fight it—adapt your policies. (github.com)

2) Get off macos-13 now—Intel users have a runway

Every brownout this month is a scheduled failure window. If you still see macos-13 in YAML, change it this week. For Apple Silicon‑friendly builds, jump to macos-15 (or macos-latest) and test for arm64 quirks. If your toolchain truly requires x86_64, GitHub added macos-15-intel so you can keep Intel around while you plan your full Apple Silicon migration. The retirement date for the macOS 13 image is December 4, 2025, with brownouts on Nov 11, 18, and 25, all 14:00–00:00 UTC. (github.blog)

Tips that save hours:

• Cache bust deliberately when switching architectures to avoid corrupt cache artifacts between Intel and arm64.
• Reinstall Homebrew dependencies fresh on arm64 runners; avoid mixed‑arch Brew prefixes.
• If you signs apps or packages, validate keychain and notarization steps on the new image before deleting the old job.

If you’re managing many repos, templatize the runner label change via reusable workflows, then roll it out with a short‑lived “watcher” job that fails if it detects macos-13 usage post‑cutover. For more hard‑won migration tactics, we wrote a hands‑on guide: macOS 13 deprecation: fix it now.

3) Finish the npm token migration before Nov 19

Classic npm tokens are nearly gone: you can’t create new ones anymore, and existing ones are revoked on November 19, 2025. Granular access tokens with write perms enforce 2FA by default; there’s a Bypass 2FA toggle for non‑interactive CI, and a 90‑day lifetime cap that will bite unattended bots if you don’t rotate. Prefer OIDC Trusted Publishing where you can. (github.blog)

Minimal‑risk rollout plan:

• Inventory CI secrets that carry npm tokens. Replace each classic token with a granular token scoped to exactly the package(s) and org, and set short expirations you’ll actually rotate.
• Enable Bypass 2FA only on the specific tokens used by your CI runners; human accounts should publish with 2FA enforced.
• For sensitive packages, move to Trusted Publishing with GitHub OIDC and eliminate long‑lived tokens entirely.

We published two quick, copy‑pasteable checklists to help teams get across the line: everything to fix by Nov 19 and a final‑week CI/CD plan.

4) Prep for Node 24 in Actions and runner image trims

GitHub has begun deprecating Node 20 for Actions and is steering the runtime to Node 24. Runners already support forcing Node 24; beginning March 4, 2026, Node 24 becomes the default. Also, image maintainers are trimming EOL tools (Node 18, Ruby 3.1, Android NDK 26, GCC 9/10) from Ubuntu/Windows/macOS images, with deployments that started November 3 and roll over a few days. Audit your workflows for implicit version assumptions and pin what you need. (github.blog)

People also ask

Should I stop using pull_request_target entirely?

No—but you should treat it like a privileged pathway. If you don’t need secrets or elevated permissions, switch to pull_request. If you must keep pull_request_target, ensure untrusted code can’t influence execution, restrict permissions, and require human approvals before secret‑using steps run. The Dec 8 ref change makes it safer, not risk‑free. (github.blog)

Do I need Intel macOS runners or can I go arm64 now?

Unless you’re tied to Intel‑only SDKs or binary plugins, you should move to arm64. Apple Silicon is the long‑term path; even Intel macOS support on Actions has an end date on the horizon. The temporary macos-15-intel label is for teams that need more time, not a reason to delay. (github.blog)

What happens if we don’t migrate npm tokens by November 19?

Local publishes that still use classic tokens will fail. Rotate to granular tokens (or OIDC Trusted Publishing) and update your CI secrets before that date. Expect more friction for tokens with write perms: 2FA by default, optional Bypass 2FA for CI, and shorter lifetimes. (github.blog)

A fast audit framework you can run today

When you’ve got dozens of repos and limited time, you can’t hand‑audit everything. Use this “PR‑Runners‑Tokens” triage to hit the highest risk first.

PR: policy and workflow safety

• List workflows using pull_request_target. For each: can it run on code from forks? Does it access secrets? If yes, move to pull_request or add approval gates.
• Update environment rules: add refs/pull/*/merge patterns for PR events; ensure the default branch is explicitly allowed for any pull_request_target job that uses environments. (github.blog)
• Set default permissions to read‑only and grant narrowly where required.
• Enable code scanning on workflow files.

Runners: images and architecture

• Search for macos-13 labels; replace with macos-15 (arm64) or macos-15-intel if you truly need x86_64. Validate signing and notarization jobs. (github.blog)
• Pin tool versions that were implicitly coming from the image (Node, Ruby, NDK, GCC). For Node‑based actions, test the Node 24 path flag on non‑critical branches. (github.blog)

Tokens: npm and publishing

• Inventory npm tokens in your secrets store; replace every classic token with granular tokens or OIDC. Lock scopes to specific packages. Set rotation alarms at 60 days for 90‑day tokens. (github.blog)
• For regulated packages, move to Trusted Publishing and eliminate human tokens for release jobs.

Real‑world gotchas (learned the hard way)

Environments and branch filters: after Dec 8, PR jobs will evaluate environment rules against execution refs. If your environment names are “prod” or “secrets‑release” and you whitelisted main or release branches, you may suddenly block PR jobs. Add the new patterns now in a PR so you can see what would break while you still have rollback. (github.blog)

Architecture drift: teams migrating to arm64 sometimes cache Intel build artifacts by accident, which causes opaque linker errors. Separate cache keys by architecture (e.g., include ${{ runner.arch }}) and clear old keys on cutover day.

OIDC misconfigurations: shifting npm to Trusted Publishing replaces one class of risk (long‑lived secrets) with another (mis‑scoped trust). Start with read‑only roles, scope to the exact repo, and require subject claims to match the workflow path.

What to do next (this week)

• Schedule a 90‑minute cutover window. During it, migrate macos-13 labels, rotate npm tokens, and merge environment rule changes for PR events.
• Run a dry‑run PR on a fork to validate the new pull_request/pull_request_target behavior with approvals and secret exposure.
• Flip a subset of non‑critical jobs to Node 24 via the runner flag; pin action SHAs and watch for regressions. (github.blog)
• Document the new token rotation policy (90 days) and create calendar events for the next two rotations. (github.blog)

Want a deeper, repo‑by‑repo playbook?

If you need to roll this across dozens of services, grab our focused guides: the last‑mile Actions cutover guide for sequencing changes, a deeper dive on pull_request_target changes, and the macOS 13 deprecation walkthrough mentioned above. If you’re also planning a platform refresh, our team can help—from audit to implementation. Start with services and implementation options or check our recent platform work.

Zooming out

Security‑led platform changes always feel inconvenient. But the direction is healthy: default‑branch‑sourced workflows for privileged PR events, short‑lived and scoped npm credentials, and a runner fleet aligned with supported operating systems and runtimes. Do the work once, codify it in reusable workflows and templates, and the next round of platform changes turns into a quick PR instead of a late‑night outage. When the lights flicker during the brownout windows, you’ll be watching dashboards—not scrambling.