The Node.js project has released a batch of security fixes addressing 16 distinct vulnerabilities spread across its three actively maintained release lines — 22.x, 24.x, and 26.x. Seven of the flaws carry a high-severity rating, six are medium, and three are low. Patched builds are now available as v22.23.5, v24.22.3, and v26.13.1, with the update also refreshing three bundled components: llhttp, undici, and sqlite.
The Headline Bug: A Memory Leak That Can Expose TLS Private Keys
The flaw drawing the most attention, tracked as CVE-2026-123864, affects the HTTPS implementation across all three supported lines and carries high severity. In the worst case, an unauthenticated client can read memory belonging to entirely different connections on the same server — memory that can include TLS private keys and the contents of other users’ requests.
The root cause is a re-entrancy problem: a specially crafted zero-length TLS write can trigger Node.js into decrypting the next TLS record while the HTTP parser is still in the middle of reading a request body. That sequence produces a use-after-free condition and an out-of-bounds read, with the end result being that the server inadvertently copies stale heap memory into what looks like a legitimate request body.
The exposure isn’t universal — a server is only vulnerable if application code calls res.flushHeaders() early in the request lifecycle and later ends the response with a non-empty chunk. Applications using plain node:http without that specific pattern are not affected, according to the official Node.js security advisory. However, any route that echoes or otherwise stores incoming request bodies gives a remote attacker a practical way to capture whatever ends up in the leaked memory.
HTTP/2 Accounts for the Bulk of the Advisory
Several more of the high-severity issues cluster around the HTTP/2 implementation. CVE-2026-123863 allows any remote client, without authentication, to abort a default-configured HTTP/2 server — notably, it’s a variant of an older flaw (CVE-2024-27983) that a previous fix failed to fully close. Two related bugs, CVE-2026-123874 and CVE-2026-123875, affect servers using the respondWithFile() method to serve files over HTTP/2: one causes memory corruption, while the other crashes the server outright when a file download is canceled mid-transfer — and researchers note that only a handful of canceled requests is enough to trigger it.
Separately, CVE-2026-123866 can cause a server to send freed response memory directly to a connected peer, potentially exposing other users’ response data in the process. CVE-2026-123865 causes a more insidious, slow-burn problem: once an HTTP/2 session encounters a protocol error during shutdown, the associated memory and file descriptors are never cleaned up, leaking resources indefinitely over the life of a long-running process. That particular issue closes a gap left behind by an earlier fix for CVE-2026-48937.
Trust and Certificate Validation Also Took a Hit
A cluster of medium- and high-severity fixes weaken certificate and session trust validation if left unpatched. CVE-2026-123872 lets a client switch the server name mid-session during a TLS 1.2 renegotiation, carrying a weaker authentication context to a host meant to enforce stricter client-certificate checks. A related issue, CVE-2026-123867, lets a host configured for a specific certificate authority silently fall back to the server’s default CA instead.
CVE-2026-123877 affects the https.Agent class, where a cached TLS session negotiated under a permissive trust policy can be reused by a request under a stricter one — with that request then incorrectly reporting authorized === true. CVE-2026-126051 lets a remote client crash TLS servers using hooks like SNICallback or addContext() via a deferred, uncaught exception.
Rounding out the medium fixes, CVE-2026-123871 prints proxy credentials directly into ERR_PROXY_INVALID_CONFIG error messages, risking exposure in logs and crash reports — echoing an earlier fix for CVE-2026-48615. CVE-2026-123868 lets a client flood a stream with tiny one-byte HTTP/2 frames that each consume roughly 114 bytes of server memory, ballooning a single stream to hundreds of megabytes. CVE-2026-123828 is a one-byte heap overflow in session.altsvc() triggered by an overly long :authority value.
The Low-Severity Trio
The three low-severity issues are comparatively narrow in scope. CVE-2026-123829 can leak the names of files that Node’s Permission Model is supposed to block access to, but only on macOS and Windows via recursive fs.watch calls. CVE-2026-106071 involves a Permission Model wildcard pattern that grants broader filesystem access than intended. CVE-2026-123862 can crash an application that calls deflate.params() while actively streaming and then calls destroy() — an uncommon but not impossible usage pattern.
Who Found What
Interestingly, researcher Chris Rohlf — working alongside Claude and Anthropic Research — is credited with reporting five of the 16 disclosed flaws, reflecting a growing trend of AI-assisted vulnerability research contributing directly to mainstream open-source security advisories. Additional reports came from the researcher known as Pimterry, the firm Trail of Bits, and several independent contributors, with core maintainer Matteo Collina responsible for fixing the majority of the batch.
What to Do Next
Node.js has shipped substantial security advisories on a near-monthly cadence recently — including October’s “Node2Shell” Brotli-related bug and an 11-flaw batch back in July — underscoring that keeping current with patch releases isn’t optional for anyone running Node.js in production. Teams should prioritize upgrading to v22.23.5, v24.22.3, or v26.13.1, starting with any public-facing HTTP/2 or HTTPS servers. Container images should be rebuilt promptly to pick up the patched runtime rather than relying on a base-image refresh alone.
Given that the TLS private-key leak (CVE-2026-123864) leaves no obvious forensic trace of exploitation, organizations that served production HTTPS traffic from a potentially vulnerable handler pattern should seriously weigh rotating their TLS certificates and keys as a precaution. And as always, anyone still running an end-of-life Node.js version is affected by definition and should treat this as additional motivation to move onto a supported release line.
Leave a Reply
You must be logged in to post a comment.