Description

undici's WebSocket client crashes the whole Node.js process during the opening handshake when a server responds with a subprotocol that the client never requested. A default WebSocket connection sends no subprotocol, but if the server's 101 response includes a Sec-WebSocket-Protocol header, undici dereferences a null value while checking it against the requested list and throws an uncaught TypeError. Because that code runs inside a microtask with no surrounding error handling, the exception propagates and terminates the process under Node's default behavior, instead of gracefully failing the connection as required by the WebSocket protocol. Any application that opens a WebSocket to an attacker-controlled or compromised server, or over a plaintext connection subject to a machine-in-the-middle, can be crashed remotely without authentication in the default configuration. This affects undici versions from 6.7.0 up to 6.28.1, from 7.0.0 up to 7.29.1, and from 8.0.0 up to 8.10.2. Users should upgrade to undici 6.28.1, 7.29.1, or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-04T18:17:51.647Z",
  "pubdate": "2026-09-04T18:17:51.647Z",
  "executiveSummary": "A null pointer dereference vulnerability exists in the WebSocket client implementation of the undici library, leading to a Denial of Service (DoS) condition.\nThe vulnerability is triggered when the library processes a 101 Switching Protocols response from a server containing an unsolicited 'Sec-WebSocket-Protocol' header.\nDue to a failure in validating server responses against client-requested subprotocols, an uncaught TypeError is generated within a microtask.\nSince this occurs outside of a try-catch block, the exception propagates to the Node.js event loop, causing the entire process to terminate abruptly.\nThe vulnerability affects multiple major versions (6.x, 7.x, 8.x) and allows remote, unauthenticated attackers—or a man-in-the-middle—to crash any application that initiates a WebSocket connection to a malicious or compromised endpoint.\nThe risk is critical for applications that rely on undici for long-lived WebSocket connections, as the crash requires no specific authentication or elevated privileges to exploit.",
  "technicalDetails": "The root cause of this vulnerability is an improper handling of the 'Sec-WebSocket-Protocol' header within the undici WebSocket handshake logic. When a client initiates a connection without specifying subprotocols, the internal state expects no such header in the server's HTTP 101 response.\nIf the server sends a 'Sec-WebSocket-Protocol' header despite the client not requesting one, the library attempts to process this header by comparing it against the list of requested subprotocols. Because the requested list is null or undefined in the default case, the logic performs a dereference on a null value.\nThis dereference operation triggers an uncaught TypeError. Because the WebSocket handshake in undici is processed within a microtask context without a designated error-handling wrapper, the exception cannot be caught by the standard application-level error handlers.\nIn the Node.js execution model, an uncaught exception in a microtask propagates to the process level, forcing an immediate exit. This bypasses the graceful connection termination required by the WebSocket protocol (RFC 6455).\nAttack Flow: 1. The client establishes a TCP connection to the target server. 2. The client sends a standard WebSocket handshake request (GET / HTTP/1.1) omitting the 'Sec-WebSocket-Protocol' header. 3. The attacker-controlled server responds with an HTTP 101 switching protocol status code, including a 'Sec-WebSocket-Protocol' header containing an arbitrary string. 4. The undici library attempts to validate the returned subprotocol against the missing request list. 5. The engine hits the null reference, throws a TypeError, and the process terminates.\nThis vulnerability is present in the following version ranges: 6.7.0 through 6.28.1, 7.0.0 through 7.29.1, and 8.0.0 through 8.10.2. The attack is fully network-exposed and can be executed over plaintext connections if the traffic is subject to machine-in-the-middle (MitM) interference, or directly if the client targets a malicious server.\nThe exploit does not require any specific memory corruption techniques; it is a logic-based crash that consistently results in a total application outage for the affected process."
}