Node.js Vulnerabilities: 16 Flaws Let Attackers Crash Servers and Steal TLS Keys
- Who should care: Anyone exposed to these Node.js vulnerabilities, meaning teams running Node.js 22, 24 or 26 that serve HTTPS or HTTP/2 directly, plus anyone still on Node 20.
- What could go wrong: A stranger crashes your API, or pulls your TLS private key out of server memory.
- Do this: Upgrade to 22.23.5, 24.22.3 or 26.13.1 and restart every Node process today.
- Worth remembering: Node 20 got no fix. It never will.
Introduction
Node.js shipped fixes for 16 security flaws on November 11, and the project rates seven of them high. The worst of these Node.js vulnerabilities can leak TLS private keys from HTTPS servers. Several others also let anyone with a network connection knock a server offline.
What Happened in the Node.js Security Release?
The Node.js project released 26.13.1, 24.22.3 and 22.23.5 after a week of advance notice. Because of that notice, admins knew a fix was coming. Most of the bugs sit in Node’s own HTTPS, TLS, and HTTP/2 code.
The headline flaw, CVE-2026-123864, triggers when a handler calls res.flushHeaders() before a request body finishes arriving. After that, a zero-length TLS write pushes the HTTP parser back in mid-body, and freed heap memory gets copied into the request.
Also, two HTTP/2 use-after-free bugs can send stale memory to a peer. Meanwhile, CVE-2026-123863 and CVE-2026-126051 crash servers with no login needed.
The rest of the batch is quieter. However, it is still nasty. TLS 1.2 renegotiation can swap the server name and skip per-host client certificate checks. Proxy passwords can also show up in error logs. Finally, the Permission Model leaks file names it should hide.
What’s the Impact?
Any app that terminates TLS or HTTP/2 inside Node is exposed to these Node.js vulnerabilities. For example, a leaked private key lets an attacker impersonate your site. Node 20 is end-of-life and gets no patches at all.
So far, nothing is in CISA KEV, and nobody has reported exploitation. Still, that window won’t stay open long. The fixes are public, and diffing a patch is how exploit writers start their week.
How to Avoid Node.js Vulnerabilities Like These
- Patch: Move to 22.23.5, 24.22.3 or 26.13.1, then restart. A new binary does nothing until the process reloads.
- Rebuild images: Pin new base tags in Dockerfiles and CI so old images stop shipping.
- Front it: Put a proxy that terminates TLS and HTTP/2 in front of Node.
- Lock renegotiation: Disable TLS 1.2 renegotiation or require TLS 1.3 if you use per-host client certificates.
- Rotate keys: If an exposed server echoed or stored request bodies before patching, issue a new TLS key.
Node.js Vulnerabilities: Indicators of Compromise (IOCs)
This is a patch release, not an attack. There are no IP, domain or hash IOCs to block. Instead, hunt for the exposure indicators below, and check each CVE against the official advisory.
You Can’t Patch the Server You Forgot
Sixteen CVEs are easy to fix on the servers you know about. However, the trouble is the Node box someone spun up for a demo two years ago.
- Secure.com’s AI teammates map every asset running Node, including the forgotten ones, and flag which still run vulnerable or end-of-life versions.
- They rank these CVEs by real exposure: an internet-facing TLS endpoint jumps the queue; an internal batch job waits.
- They test what attackers would test, then hand your team a verified fix list instead of a raw scan dump.
- Your team sets the rules. Teammates draft the tickets and track every restart to closure.
- Proof is built in, so you can show auditors exactly when each server was patched.
Governed Defense, Powered by Offense. Attack. Harden. Prove. Repeat.
Conclusion
The November release closes 16 Node.js vulnerabilities, and the fix is simple on paper: upgrade, restart, rebuild your images. Even so, the hard part is finding every Node process that needs it, and moving anything still on Node 20 to a supported line.
