Node.js Security Release: What to Patch Today

The latest Node.js security release landed on January 13, 2026 and it’s a big one: eight CVEs across all active lines. If you operate public-facing Node servers, this Node.js security release is not something to pencil in for next sprint—you’ll want a controlled, tested rollout within 24–72 hours.

Here’s the thing: three issues are rated High, four Medium, and one Low, but severity alone doesn’t tell the whole story. Depending on how you use HTTP/2, TLS callbacks, AsyncLocalStorage, and the permission model, your real-world exposure can swing from “low risk” to “someone can crash us from the internet.” Let’s decode the changes, map them to practical impact, and then walk through an upgrade plan you can execute this week.

What changed in the January 13, 2026 drop

Four supported lines received updates: 20.20.0, 22.22.0, 24.13.0, and 25.3.0. Two bundled dependencies were bumped to address public vulnerabilities: c-ares 1.34.6 and undici 6.23.0/7.18.0. The release addresses eight CVEs, notably:

High severity:

• CVE-2025-55131 — Timeout-based race can leave Buffer.alloc/TypedArrays non‑zeroed under specific vm timeout conditions, risking secret leakage in edge scenarios.
• CVE-2025-55130 — Symlink tricks can bypass the permission model’s filesystem guards.
• CVE-2025-59465 — Malformed HTTP/2 HEADERS can crash servers if secure socket errors aren’t handled.

Medium severity highlights:

• CVE-2025-59466 — Async hooks can yield uncatchable stack overflow crashes, impacting apps that lean on AsyncLocalStorage or custom hooks.
• CVE-2025-59464 — TLS client certificate parsing leak can enable remote memory growth via repeated handshakes.
• CVE-2026-21636 — UDS connections can slip past network permissions in the experimental permission model (v25).
• CVE-2026-21637 — Exceptions in TLS PSK/ALPN callbacks can bypass normal handlers, causing crashes or FD leaks.

Low severity:

• CVE-2025-55132 — fs.futimes() can modify timestamps despite read-only expectations in the permission model.

You’ll see chatter about a prior Jan 7 release; this later drop adds more fixes and clarifies hardening guidance. If you paused on the earlier patches waiting for quieter waters, this is your cue to move.

Why this Node.js security release matters to your stack

Not all teams are equally exposed. Use this quick map to triage.

Highest urgency if any apply:

• You run public HTTP/2 on Node core or via frameworks that don’t attach explicit secure socket error handlers.
• You depend on AsyncLocalStorage for request-scoped context (observability, tracing, auth) and handle untrusted recursion or deep call chains.
• You enabled the experimental permission model in production (or CI that runs untrusted tasks).
• You parse or log TLS client certificate fields (mutual TLS on internal control planes counts).

Moderate urgency if:

• Your services don’t expose HTTP/2 publicly, and you have belt-and-suspenders error handling on TLS sockets.
• You don’t use AsyncLocalStorage or custom async_hooks.
• You’ve never touched the permission model flags.

Lower urgency if:

• Your traffic is exclusively HTTP/1.1 behind a proxy that terminates TLS and downgrades to HTTP/1.1 for app hops.
• You’re on managed PaaS that pins Node to the patched lines and auto-rolls base images—but verify, don’t assume.

The 48‑hour patch playbook (copy this to your issue tracker)

Day 0 (today):

1) Inventory reality. For each service, record Node major/minor, base image tag (e.g., node:22-bullseye or node:22.22.0-alpine), whether HTTP/2 is on, and whether AsyncLocalStorage/async_hooks is used. If you can’t automate it, a one-liner inside each container helps: node -v, check for http2 module usage, and a quick search for AsyncLocalStorage.

2) Cut a release branch per service. Bump Node to 20.20.0, 22.22.0, 24.13.0, or 25.3.0 as applicable. If you’re on Docker, pin the exact version tag, not a floating major. In CI, switch to npm ci with --ignore-scripts for the build step to reduce supply‑chain risk during the upgrade.

3) Upgrade undici if you vendor or pin it directly. Most teams consume undici transitively via frameworks; still, check locks. While you’re there, refresh OpenSSL and c-ares via your base image by rebuilding from a patched upstream.

4) Add an explicit error handler for secure sockets. If you expose HTTP/2, attach an error listener on the secureConnection path and ensure it never throws. You want to log and close—not crash the process.

5) Turn on traffic replay in staging. Mirror a slice of real production traffic to the patched builds. Watch memory, file descriptors, GC pauses, and TLS connection churn.

Day 1:

6) Canary one region or 5% of users. Use health‑based progressive rollout. Bake for 2–4 hours minimum. Verify dashboards: error rates, p99 latency, CPU, RSS, and socket counts.

7) Rotate secrets if you used vm with timeouts in workloads accessible to less‑trusted code paths. The buffer zero‑fill race is hard to exploit, but the cost of a rotation is often lower than the risk for multi‑tenant systems.

8) Rebuild all long‑lived workers. CI runners, schedulers, and job consumers tend to lag. If they process untrusted payloads (media, HTML, PDFs), they deserve the same treatment as public web nodes.

Day 2:

9) Roll out globally with tight alerts. Keep a rollback ready that flips back to the previous Node image digest.
10) Retrospective. Document what broke, what was noisy, and the one thing you’ll automate before the next drop.

“Can I just bump undici and call it a day?”

No. The undici and c-ares bumps are only part of the story. Several CVEs patch Node core behavior (buffer allocation races, async hooks crash behavior, permission model gaps). If you only update a library, you’ll miss core fixes. Upgrade Node itself, rebuild your base images, and then let your package manager refresh transitive dependencies.

Hardening moves worth keeping after you upgrade

These aren’t band‑aids; they’re upgrades to your operational posture.

• Wrap TLS and HTTP/2 errors explicitly. A tiny server.on('secureConnection', sock => sock.on('error', handler)) can be the difference between a logged event and a crashed process.
• Place HTTP/2 behind a proven edge. If you don’t need end‑to‑end h2, terminate at a gateway that already battle‑tests header validation, then speak HTTP/1.1 to Node.
• Budget for memory leak SLOs. If you rely on socket.getPeerCertificate(true), add leak detection in pre‑prod: sustained handshake storms shouldn’t grow RSS unbounded. Build a chaos test that pounds mTLS handshakes for 15 minutes.
• Use the permission model with care. It’s still evolving. Restrict it to sandboxed tasks until you’ve threat‑modeled UDS and symlink edge cases. Don’t rely on it as your only guardrail for multi‑tenant risk.
• Keep AsyncLocalStorage focused. If untrusted inputs can influence recursion depth, gate that work or bound it explicitly. Don’t depend on stack exhaustion behavior to “handle” bad paths.

People also ask

Which Node.js versions are patched, exactly?

As of January 13, 2026: 20.20.0, 22.22.0, 24.13.0, and 25.3.0. If your cloud runtime abstracts the runtime (serverless, managed PaaS), check their release notes and the image digests they use. If you run Docker, pin exact tags and verify with node -v at container start.

Does this affect Next.js, NestJS, Express, or Fastify?

Frameworks ride on Node’s core behaviors. If you serve HTTP/2 or rely on AsyncLocalStorage (common in tracing and auth context), you’re in scope. Framework updates can help, but they don’t replace the Node upgrade. Treat it as a platform patch first, then validate your framework layer.

Is the permission model production‑ready?

It’s useful but still maturing. This release includes multiple permission model fixes, including a symlink bypass and UDS escape hatch. For now, prefer container isolation, seccomp profiles, read‑only filesystems, and user namespaces as your first line, then layer the permission model for defense‑in‑depth.

Do containers and proxies protect me from the HTTP/2 crash?

They can help, but crashing the app process is still crashing the app process. If your Node instance terminates under malformed headers, the pod will restart. That’s an availability incident. Terminate h2 at the edge if you can; otherwise ensure robust error handlers and aggressive connection limiting.

Do I need to rotate secrets because of the buffer zero‑fill race?

If you run vm with timeouts in semi‑trusted environments or multi‑tenant code execution, yes—rotate. For most monolithic web apps that don’t execute untrusted code, the exploitation path is far narrower. Make the call based on your workload model.

A fast test matrix you can trust

Upgrade fatigue is real. The antidote is a tight set of tests that catch regressions without slowing you down:

• Protocol abuse tests: replay malformed HTTP/2 headers against staging; assert the process survives and metrics stay flat.
• TLS churn: spin up a job that opens and closes 10,000 mTLS connections; watch RSS and FD counts for plateaus.
• Context continuity: run an AsyncLocalStorage test through your hottest endpoints and confirm your correlation IDs don’t disappear at depth.
• Permissions smoke: if you use the permission model, attempt a crafted symlink escape and a local UDS connect without --allow-net; both should fail.

How to communicate this to the business

Executives don’t need CVE trivia; they need risk framing and a plan. Keep it to three bullets: 1) external crash risk via HTTP/2, 2) defense‑in‑depth gaps in the permission model, 3) our plan to patch with measurable blast radius controls. If you need help shaping the message, our team has shipped dozens of time‑boxed hardening sprints; see what we do and how we execute under pressure in our approach to delivery and the work highlighted in our portfolio.

Related platform changes to keep on your radar

Patching Node is one piece of a broader 2026 platform hygiene story. For example, browser privacy changes keep nudging server designs toward more durable first‑party data and resilient session handling—see our take in this practical playbook on third‑party cookies in 2026. If your backend manages identity, tokens, or consent logs, these trends intersect with how you reason about secrets in memory and error handling under stress.

What to do next (developers)

• Patch Node to 20.20.0, 22.22.0, 24.13.0, or 25.3.0; rebuild images; roll out with a canary and a 2–4 hour bake per stage.
• Add explicit error handlers on secure sockets; keep them crash‑proof.
• Validate AsyncLocalStorage behavior under depth and load; watch for error‑handler bypasses.
• If you use the permission model, exercise UDS and symlink tests; keep it behind stronger isolation layers.
• Close the loop: traffic replay, secret rotation if you run vm with timeouts, and a short retro to automate one new guardrail.

What to do next (business and product owners)

• Authorize a 48‑hour hardening window with a temporary feature freeze on affected services.
• Ask for the canary health report (error rates, latency, restarts) before approving full rollout.
• Budget recurring “patch weeks” each quarter. The cost is modest compared to a public outage or an incident report to customers.

Need a second pair of hands?

If you want an outside team to pressure‑test your upgrade plan or run the rollout overnight, we can help. Start with our security and platform services, skim our latest engineering notes, and drop us a line via our contact form. We ship under constraints and leave you with repeatable scripts for the next release.

Zooming out

Two security drops in one week isn’t ideal, but it’s not a crisis; it’s the reality of a healthy platform responding to real reports. The teams that fare best are the ones who treat patching as a practiced drill: inventory fast, upgrade with guardrails, verify with traffic replay, and communicate clearly. Do that, and this Node.js security release becomes a routine Tuesday—not a fire drill.