Node.js Security Release: Patch Now, Test Smarter

The latest Node.js security release dropped on January 13, 2026, and it’s not optional hygiene. This Node.js security release patches three high-severity issues across all supported lines, plus dependency fixes in Undici and c-ares that many of you transitively ship. If you run 20.x, 22.x, 24.x, or 25.x in production, you should plan an expedited rollout. (nodejs.org)

What changed in the January 2026 releases?

On January 13, 2026 the project shipped patched builds for all active lines: 20.20.0 (Iron, LTS), 22.22.0 (Jod, LTS), 24.13.0 (Krypton, LTS), and 25.3.0 (Current). Six days later, 25.4.0 followed with additional improvements—so if you’re on 25.x, target 25.4.0+. (github.com)

Scope and severity at the project level: three High, four Medium, one Low. The big ones you’ll care about:

• CVE-2025-55131: timeout/race can expose uninitialized memory in Buffer.alloc/TypedArray under specific conditions (notably when vm timeouts are involved). That means secrets could leak cross-requests in the same process. (nodejs.org)

• CVE-2025-55130: permission model symlink handling could escape allowed paths, undermining sandboxes that rely on --permission flags. (nodejs.org)

• CVE-2025-59465: malformed HTTP/2 HEADERS can crash servers via unhandled TLSSocket errors—classic remote DoS if you’re not explicitly guarding socket errors. (nodejs.org)

The announcement landed at a URL originally used for a December pre‑advisory; publication and most details updated on January 13. If you saw conflicting dates in feeds, that’s why. (openwall.com)

Dependency fixes you probably ship (even if you don’t know it)

Undici and c‑ares were bumped across the lines to address public vulnerabilities. Undici 6.23.0/7.18.0 fixes a decompression-chain issue (CVE‑2026‑22036) that can force heavy CPU and memory usage by stacking Content‑Encoding steps. c‑ares 1.34.6 addresses a use‑after‑free bug (CVE‑2025‑62408). If your workloads call external services or do DNS at scale, these matter. (nodejs.org)

Is it safe to wait a week?

Short answer: no—treat this like a platform update. Two of the issues can crash processes or expose memory content, and all fixes exist in released builds. If you need an extra push: this was the second Node security drop in six days; we also saw a follow‑up 25.4.0 shortly after. Secure and move on. (byteiota.com)

48‑hour rollout playbook for lean teams

Here’s the thing: most outages happen in test, not in the patch. The trick is to stage risk and verify the exact failure modes this release touches.

Day 0: triage and scoping (1–2 hours)

• Inventory Node runtimes per service: node -p "process.version + ' ' + process.versions.modules" in each container or host. Note any 20.x/22.x/24.x/25.x targets and the CI runners building them.

• Confirm your target versions: 20.20.0, 22.22.0, 24.13.0, 25.3.0+ (or 25.4.0 if you’re on Current). If you run a pinned base image, check your image tags aren’t pulling unpatched layers. (github.com)

• Snapshot current Undici/c‑ares versions used at runtime. In Node, Undici often arrives via global fetch (recent lines) or your client stack. In app repos: npm ls undici (if vendored) and test a quick runtime probe: node -p "globalThis.fetch ? 'has fetch' : 'no fetch'". For c‑ares, you consume it inside Node’s DNS stack—ensure your Node binary is patched. (openjsf.org)

Day 1: patch and run focused tests

• Upgrade Node in your build images. For Debian/Ubuntu nodes built from source, bump to the patched tags. For Docker, pick distro images that have landed the versions above. Validate with node -v.

• Add a buffer‑zeroing test to catch CVE‑2025‑55131 class regressions: hammer Buffer.alloc() under vm timeouts and concurrency, then inspect for non‑zero bytes. Even with the fix, this test guards future refactors.

• Permission model test: if you use --permission, write a harness that tries relative symlink escapes from allowed dirs and expects denial. Try both read and write. (nodejs.org)

• HTTP/2 hardening: even with the fix, add explicit socket.on('error', ...) on TLSSocket or your HTTP/2 server’s secure connection path. Run fuzzed headers against a test instance and watch for clean closes over crashes. (nodejs.org)

• Undici stress: replay responses with deep Content‑Encoding chains; ensure CPU and memory stay bounded on 6.23.0/7.18.0+. If you pin Undici, bump per advisory. (nvd.nist.gov)

Day 2: canary and ramp

• Ship the patched runtime to 5–10% of traffic behind a feature flag or deployment ring. Watch error rates, p95/p99 latency, and heap growth.

• If clean for 2–4 hours under peak, ramp to 25–50%, then 100% within your maintenance window.

Deep dive: where each CVE bites in real life

Buffer alloc race (CVE‑2025‑55131)

The risky path shows up when your service allocates buffers and exposes contents externally—logging, metrics, response bodies—while vm timeouts or concurrency interrupt initialization. After the fix, allocation and exposure are no longer interleaved. If you run multi‑tenant code execution, workers with time limits, or aggressive timeouts, prioritize this. (nodejs.org)

Permission model symlink escape (CVE‑2025‑55130)

Teams that embraced --permission to confine file I/O are the most exposed. A carefully crafted chain of relative symlinks could walk out of the allowed subtree. Post‑patch, symlink APIs require explicit read/write permission and resolve under the same checks. Re‑test any data import/export jobs and plugin architectures that lean on symlinks. (nodejs.org)

HTTP/2 HEADERS crash (CVE‑2025‑59465)

Environments terminating TLS upstream sometimes assume the edge will sanitize everything. Don’t. If your Node process handles HTTP/2 directly, a malicious peer could still send HEADERS that trigger an unhandled socket error. The fix adds a default error handler; you should still own your error paths. (nodejs.org)

Undici’s decompression chain (CVE‑2026‑22036)

Undici prior to 6.23.0/7.18.0 didn’t bound Content‑Encoding chain depth. A server could stack thousands of encodings, burning CPU and memory. If you hit third‑party APIs, you’re exposed—even if your own servers are well‑behaved. Update to ≥6.23.0/7.18.0; Node’s patched lines include compatible bumps. (nvd.nist.gov)

c‑ares use‑after‑free (CVE‑2025‑62408)

c‑ares 1.34.6 is a focused security release. DNS pressure plus edge cases in query handling could lead to crashes. If your service does a lot of outbound calls, protect your availability by ensuring your Node binary links the fixed version. (c-ares.org)

People also ask: quick answers for busy leads

Which Node.js versions are considered safe today?

For January 2026: 20.20.0, 22.22.0, 24.13.0, and for Current choose 25.3.0 or, better, 25.4.0. Validate in your containers with node -v. (github.com)

Do I need to rebuild native addons?

If you’re staying within the same major line, usually not—ABI is stable within a line. Still, run CI on modules with native bindings (bcrypt, sharp, grpc‑native) after bumping Node.

Should I also patch my OS for DNS or HTTP libraries?

Yes, keep base images current. The Node release includes its own dependency updates (e.g., c‑ares) but your distro may carry separate DNS stacks. Pull fresh base images and run apt/yum updates as part of the bump. (ubuntu.com)

Can I just upgrade Undici and call it a day?

No. Some vulnerabilities are in Node core (Buffer, permission model, HTTP/2). Patch the runtime first; then ensure Undici is ≥6.23.0/7.18.0 if you vendor it. (nodejs.org)

Test focus: what to prove before you ramp

• Memory safety: run synthetic load that allocates and serializes buffers, verify no unexpected non‑zero data appears. Add a canary that hashes fresh buffers and alarms on anomalies.

• Sandbox integrity: with --permission enabled, run negative tests for symlink reads/writes across directories; verify denials are logged and audited.

• HTTP/2 resilience: replay malformed HEADERS with oversized HPACK data against staging; confirm graceful close and process survival. (nodejs.org)

• Client hardening: if you use fetch/Undici directly, script deep encoding chains and assert latency/memory ceilings on the patched versions. (nvd.nist.gov)

Operational guardrails you can keep after this week

• Runtime SLOs: define p99 CPU/memory budgets per service and alert on deltas after a Node upgrade.

• Canary discipline: minimum two rings (5% and 25%) with automated rollback on error‑rate spikes.

• CVE watch: subscribe your security channel to Node’s advisories and GitHub release RSS for nodejs/node. Keep a recurring task to review Undici and c‑ares advisories monthly. (github.com)

Zooming out: why the cadence feels intense

The Jan 13 drop followed another security release the prior week, and a Current follow‑up landed on Jan 19. That’s not a crisis; it’s the ecosystem responding quickly to issues that affect high‑traffic production runtimes. Your job is to normalize fast, low‑drama rollouts. (byteiota.com)

What to do next (today, this week)

• Today: bump your runtime to a patched line; for 25.x aim for 25.4.0+. Rebuild images, run smoke tests, deploy to a canary. (github.com)

• This week: add permission‑model and HTTP/2 negative tests to regression suites. Validate Undici ≥6.23.0/7.18.0 and audit any vendor pin. (nvd.nist.gov)

• Quarter: document a Node upgrade playbook, including service owners, rollback steps, and performance baselines. Train on call‑safe patching.

Need help shipping safely?

If you want a second set of eyes on your patch plan or a hardening review, our team runs pragmatic upgrade sprints and threat‑modeling workshops for Node stacks. See the scope of our security and engineering services, browse a few case studies, or contact us to schedule a rapid response slot. If you’re triaging other platform risks this month, our write‑up on January 2026 Patch Tuesday prioritization might help, and we keep a rolling Node.js patching checklist up to date.

Cheat sheet: fast commands you can copy

• Confirm runtime: node -v && node -p "process.versions"

• Check Undici in app deps: npm ls undici || pnpm ls undici || yarn why undici

• Validate fetch availability (newer Node): node -p "typeof fetch"

• Permission model smoke: run Node with --permission and try to read a file outside the allowed dir via a relative symlink; expect an error. (nodejs.org)

Final word

Patching Node shouldn’t be a weekend‑ruining event. Treat Node.js security release updates like kernel updates: quick inventory, targeted tests for the specific failure modes, a disciplined canary, then move on. The fixes are out, the versions are clear, and the tests above are enough to ship with confidence. If anything looks hairy in your stack, reach out—we’ve shipped this upgrade pattern countless times and can help you do it safely at speed.