Node.js January 2026 Security Release: Ship Safe Now

The Node.js January 2026 security release landed on January 13 and touches every active line: 20.x, 22.x, 24.x, and 25.x. It fixes three high, four medium, and one low-severity issues, with new builds 20.20.0, 22.22.0, 24.13.0, and 25.3.0. If you run servers on Node, this isn’t optional. This guide explains what changed, what’s actually risky, and how to roll out the Node.js January 2026 security release without breaking production. (nodejs.org)

What changed—and why it matters

Here’s the thing: the headline isn’t “just patch.” It’s that several fixes close gaps many teams don’t test for—buffer zeroing under timeouts, permission model escapes via symlinks and Unix domain sockets, and an HTTP/2 crash path that nukes your process if you don’t wire up errors correctly. (nodejs.org)

Concrete updates you’ll see in the changelogs and builds:

Versions released (Jan 13, 2026): 20.20.0, 22.22.0, 24.13.0, 25.3.0. These are labeled as security releases and include dependency bumps to c-ares 1.34.6 and undici (6.23.0/7.18.0), plus notable core patches. (nodejs.org)

High severity fixes

• CVE-2025-55131: timeout-driven race conditions could cause Buffer.alloc and some TypedArrays to expose non-zeroed memory. If your code returns raw buffers, streams them, or logs them, you could leak secrets. The fix enforces safe initialization. (nodejs.org)

• CVE-2025-55130: permission model symlink handling now requires explicit read/write on targets, closing a crafted-relative-symlink path escape. If you rely on --permission for isolation, this is a big deal. (nodejs.org)

• CVE-2025-59465: malformed HTTP/2 HEADERS could trigger an unhandled TLSSocket error, crashing the process (remote DoS). Node now installs a default error handler at the TLS layer. (nodejs.org)

Medium/low severity fixes

• CVE-2025-59466: stack overflows with async_hooks could bypass uncaughtException and kill the process. The patch improves one edge case; you still need to bound recursion and validate input. (nodejs.org)

• CVE-2026-21636: permission model didn’t consistently guard Unix Domain Socket connections; UDS now falls under network checks. (nodejs.org)

• CVE-2026-21637: exceptions in TLS PSK/ALPN callbacks could bypass handlers, causing crashes or file descriptor leaks. Fixed to route through proper paths. (nodejs.org)

• CVE-2025-55132: fs.futimes() could alter timestamps under read-only permission sets; it’s now disabled when the permission model is on. (nodejs.org)

• CVE-2025-59464 (24.x only): TLS client-certificate parsing leaked memory when enumerating X.509 fields—exploitable if you call socket.getPeerCertificate(true). Fixed in 24.12.0 and included in 24.13.0. (nodejs.org)

Will this hit my stack?

Let’s get practical. You’re at higher risk if any of these sound familiar:

• You use the vm module’s timeout option (sandboxing, templating, per-tenant eval) and return or log buffers. CVE-2025-55131 is squarely in your blast radius. (nodejs.org)

• You enabled the experimental permission model with --permission, especially in multi-tenant runtimes, Git hooks, or plugin architectures. The symlink and UDS fixes matter immediately. (nodejs.org)

• You run HTTP/2 servers (Express via http2, Fastify over TLS/ALPN, custom gRPC gateways) and haven’t attached low-level TLS error handlers. The default handler helps, but audit your code. (nodejs.org)

• You rely on AsyncLocalStorage (common in Next.js/NestJS tracing or auth context) or custom async_hooks. Mitigation landed, but design still matters for deep recursion paths. (nodeweekly.com)

• You inspect TLS client certificates in 24.x for mutual TLS—e.g., B2B APIs—via getPeerCertificate(true). Confirm you’re on 24.13.0+. (nodejs.org)

Primary keyword check: plan for the Node.js January 2026 security release

Use a disciplined rollout. The release was postponed twice (from mid‑December 2025 to January 13, 2026) to complete backports and CITGM, which means it’s safe to ship—but test. (nodejs.org)

PATCH‑NODE: a field-tested checklist

When clients ask how to move fast without breaking prod, this is the sequence we use.

Pin and prepare: lock your package manager, capture current node -v, and snapshot autoscaling and error baselines. Note your target: 20.20.0, 22.22.0, 24.13.0, or 25.3.0. (nodejs.org)

Apply upgrades in a staging env that mirrors TLS/HTTP/2 and permission flags. Rebuild images, invalidate layers aggressively, and redeploy. Verify c-ares and undici are the new versions via process.versions output or runtime banners. (nodejs.org)

Test the edges:

• Hammer HTTP/2 with malformed headers using your synthetic test suite; confirm no process exits and that errors are logged once. (nodejs.org)

• Run a stress test that exercises vm timeouts while allocating buffers; ensure outputs are zeroed and no sensitive data appears in logs. (nodejs.org)

Configure TLS callbacks: if you use PSK/ALPN callbacks, wrap them to avoid synchronous throws; confirm exceptions flow to tlsClientError. (nodejs.org)

Harden permissions: turn on --permission only where you can enumerate exact needs; audit symlinks in working dirs; disallow untrusted relative links in uploads; and ensure UDS access is granted explicitly or blocked. (nodejs.org)

Notify stakeholders: this is a security ship. Create a short‑term freeze window and tell SRE/on‑call what to watch.

Observe: deploy canaries; track process restarts, TLS handshake errors, heap growth under mTLS, and HTTP/2 session resets. The TLS client-cert leak was confined to 24.x but watch memory anyway. (nodejs.org)

Document: record the Node, OpenSSL, c‑ares, and undici versions you’ve landed; link your runbooks for future incidents. (nodejs.org)

End-to-end rehearse: run a game day on recursion-heavy endpoints to ensure async_hooks paths don’t take down the process. (nodeweekly.com)

Risk-based prioritization you can defend

If you’re triaging across many services, prioritize like this:

1) Public-facing HTTP/2 servers with TLS (DoS risk, CVE‑2025‑59465). 2) Workloads that expose buffers/log raw binary data coupled with vm timeouts (CVE‑2025‑55131). 3) Anything running the permission model with symlinks or UDS (CVE‑2025‑55130, CVE‑2026‑21636). 4) TLS servers using PSK/ALPN callbacks (CVE‑2026‑21637). 5) 24.x services doing mTLS client-cert introspection (CVE‑2025‑59464). 6) Apps using AsyncLocalStorage/async_hooks in recursion-prone code (CVE‑2025‑59466). (nodejs.org)

As for timelines, most teams should have production upgraded within 72 hours. Regulated environments can phase canaries in 24 hours, two waves in 48, global completion by 96. The Node team intentionally shipped on Tuesday, January 13, 2026, during business hours to help global rollouts. (nodejs.org)

“Is Node in a security crisis?”

Fair question. Two closely spaced releases in January made headlines. But zooming out: the fixes strengthen the young permission model, harden TLS and HTTP/2 error handling, and close a tricky buffer-init race. That’s progress, not instability—and the release engineering notes show deliberate backport testing and CITGM runs before shipping. (nodejs.org)

Community coverage called out the unusual cadence, but also emphasized that framework and library authors have work to do around recursion and error handling—especially where async_hooks is common. The takeaway: patch now and keep pressure on upstreams to validate deep stacks and error paths. (nodeweekly.com)

People also ask

Which exact Node version should I deploy today?

Match your line: 20.x → 20.20.0, 22.x → 22.22.0, 24.x → 24.13.0, 25.x → 25.3.0. If you’re on 24.x and use mutual TLS, prioritize that upgrade first. (nodejs.org)

Is Node 20 still supported?

Yes—Node 20 is in Maintenance LTS through April 30, 2026. If you’re still on 18, you’re out of support; plan migrations now. (github.com)

Do I need to change my code after patching?

Probably a little. Add or verify TLS error handlers, bound recursion, and review any permission-model assumptions (especially around symlinks and UDS). The runtime is safer now, but safe-by-default isn’t a license to be careless. (nodejs.org)

Integration notes for Express, NestJS, Next.js, and gRPC

Express and NestJS mostly sit on core HTTP/TLS, so the default TLS error handler helps—but attach explicit socket error listeners anyway to maintain consistent logging and metrics. For Next.js/React SSR stacks that lean on AsyncLocalStorage for request context, limit recursion risks and fuzz deep middleware chains in tests. gRPC over HTTP/2 will benefit directly from the HEADERS fix but still deserves load testing under malformed frames. (nodejs.org)

On the permission model: if you’re bundling a plugin system or CLI with scaffolding commands (think nest new or project generators), run with a deny-by-default posture and enumerate UDS/network permissions explicitly. Validate symlinks on template extraction and disallow relative links in user-supplied archives. (nodejs.org)

Release artifacts and proof for auditors

When compliance asks “what exactly changed,” point them to the official release posts and tags. You’ll see the CVE references and the specific commits that add the TLS error handler, symlink permission enforcement, futimes behavior change, and the buffer-init refactor. Attach SHASUMs from the release post to your change record. (nodejs.org)

Operational guardrails we keep in place

• Crash-only design on the edge. Keep a watchdog that restarts crashed processes fast, with bounded backoff, while you surface crash signatures. The HTTP/2 fix reduces unhandled errors, but defense-in-depth wins. (nodejs.org)

• mTLS introspection hygiene. If your 24.x services enumerate client certificates, simulate hostile clients that connect/disconnect rapidly and confirm memory stays flat. (nodejs.org)

• UDS allowlists. Don’t let arbitrary paths sneak into socketPath. Constrain to a directory and ownership with runtime checks. The new check helps; your policy stops foot‑guns. (nodejs.org)

• Recursion budgets. Where untrusted input can grow nested structures (parsers, serializers, template engines), set explicit depth limits and test. The async_hooks mitigation is not a get‑out‑of‑jail card. (nodeweekly.com)

Related resources from Bybowu

If you want a concise triage first, read our Node.js Security Release: What to Patch Today for a quick severity map and upgrade path. For broader patch hygiene across your fleet, our playbook in January 2026 Patch Tuesday: What to Fix First shows how we schedule and communicate risk. If you need hands-on help, see what we do or drop us a note via contacts.

What to do next (developers)

• Upgrade to the fixed version for your line: 20.20.0, 22.22.0, 24.13.0, or 25.3.0. Ship canaries within 24 hours. (nodejs.org)

• Add explicit TLS and HTTP/2 error handlers and verify a single, structured log event per failure.

• Audit symlinks in build, deploy, and runtime paths; block relative symlinks in user uploads.

• Gate UDS access by policy (env var allowlist, container mounts).

• Fuzz recursion paths where AsyncLocalStorage or async_hooks are used; enforce depth limits. (nodeweekly.com)

• For mTLS on 24.x, stress-test many short-lived client connections while scraping memory; confirm no growth trend. (nodejs.org)

What to do next (business leaders)

• Approve a 48–72 hour maintenance window for production upgrades and follow‑up tests.

• Ask for a one-page “post-upgrade” report listing Node, OpenSSL, c‑ares, and undici versions and the CVEs addressed—your auditors will thank you. (nodejs.org)

• Fund a Q1 effort to formalize permission-model usage (policy, tests, and observability). This pays off the next time Node tightens the rules.

• If your stack spans React 19/Next.js SSR, budget time to validate AsyncLocalStorage and middleware recursion risks after the update. For migration notes, our React 19 migration guide pairs well with this release. (nodeweekly.com)

Final thought

Security isn’t just patching faster; it’s designing so a missed patch doesn’t sink you. The Node.js January 2026 security release gives you stronger defaults. Pair it with explicit error handling, strict permissions, and recursion budgets, and you’ll turn a reactive sprint into a durable posture for the rest of 2026. (nodejs.org)