Node.js patches critical HTTP/2 crashes and TLS memory leaks
Node.js released security updates for versions 22, 24, and 26 to fix 16 vulnerabilities, including high-severity bugs that allow remote crashes and data leakage in HTTP/2 and HTTPS servers.
The Node.js project has released emergency security patches for its supported runtime lines to address sixteen vulnerabilities, several of which pose immediate risks to web servers. The update covers versions 22.23.5, 24.22.3, and 26.13.1, fixing flaws that allow unauthenticated attackers to crash services or leak sensitive memory contents. These fixes are critical for any organization running self-hosted applications on these specific release branches.
What happened
The most severe issues involve the HTTP/2 and HTTPS implementations within the Node.js core. One flaw, tracked as CVE-2026-123863, allows a remote client to crash an HTTP/2 server simply by sending a request where the server replies before the request body is fully received. This behavior is described as typical for many default configurations, making a wide range of deployments vulnerable to denial-of-service attacks over both encrypted and cleartext connections.
Another critical vulnerability, CVE-2026-123866, enables a client to trigger a memory leak that exposes data from other active connections. In some scenarios, this can include responses intended for different users. A third high-severity bug, CVE-2026-123864, affects HTTPS servers specifically. It allows an unauthenticated attacker to read server memory, potentially exposing TLS private keys and other users' request data, provided the application code calls specific response methods in a certain order.
The security advisory lists no workarounds for these issues, stating that updating to the fixed versions is the only remediation path. Servers running end-of-life versions, such as 20.x and 25.x, receive no patches and remain permanently vulnerable to these exploits. The project did not report any active exploitation in the wild at the time of release, nor did it specify whether compromised servers must rotate their TLS keys after patching.
Key details
- Fixed versions are 22.23.5, 24.22.3, and 26.13.1; all three supported lines are affected.
- CVE-2026-123863 allows unauthenticated clients to crash HTTP/2 servers via premature responses.
- CVE-2026-123864 permits reading of TLS private keys and other connection data from HTTPS server memory.
- End-of-life releases like Node.js 20.x and 25.x do not receive fixes and remain vulnerable.
- Five of the vulnerabilities were reported by Chris Rohlf in collaboration with Anthropic Research.
- The advisory explicitly states there are no known workarounds other than upgrading the runtime.
Background
Node.js is a JavaScript runtime widely used for building scalable network applications. Its built-in HTTP/2 and HTTPS modules handle low-level network protocols, including TLS encryption and multiplexed streams. When vulnerabilities exist in these core modules, they affect every application using them, regardless of the higher-level framework like Express or Fastify. This differs from application-level bugs, which developers can often patch in their own code. Core vulnerabilities require waiting for the runtime maintainers to issue a new binary or source release.
HTTP/2 improves performance by allowing multiple requests over a single connection, but it introduces complex state management for streams and headers. Bugs in this area often lead to resource exhaustion or memory corruption because the server must track the state of many concurrent interactions. Similarly, TLS handling involves managing cryptographic keys and session data in memory. If a flaw allows reading outside the intended memory buffer, attackers can extract secrets that should remain protected by the encryption layer.
Why it matters
For teams running self-hosted software, these vulnerabilities represent a direct threat to availability and confidentiality. A crash flaw means an attacker can take down your API or web interface with minimal effort, causing downtime that impacts users and revenue. Since the trigger condition for the crash is common in default setups, many services may be exposed without any custom configuration changes. This makes timely patching essential for maintaining service reliability.
The memory leakage issues are even more concerning for security-conscious organizations. If an attacker can read TLS private keys, they can potentially decrypt past or future traffic if they also capture network packets. Leaking other users' request data violates privacy expectations and may breach compliance requirements like GDPR or HIPAA. Because these flaws reside in the runtime itself, application-level firewalls or input validation may not fully mitigate the risk, leaving the underlying server process exposed.
Additionally, the lack of fixes for end-of-life versions forces a difficult decision for teams still on Node.js 20 or 25. They must either undertake an urgent migration to a supported version or accept the risk of running vulnerable infrastructure. This highlights the operational burden of keeping runtimes current, as delaying upgrades can lead to situations where no patch is available when a critical flaw is discovered.
What you can do
- Identify all servers running Node.js 22, 24, or 26 and plan an immediate upgrade to the fixed versions.
- Check if any services are running on end-of-life versions like 20.x or 25.x and prioritize their migration.
- Review application logs for unusual crashes or reset connections that might indicate attempted exploitation.
- Consider rotating TLS private keys and certificates if you suspect any server was vulnerable to CVE-2026-123864.
- Test your application thoroughly after upgrading, as minor version bumps can sometimes introduce breaking changes.
- Monitor the Node.js security channel for further advisories, especially regarding the need for key rotation.



