CVE-2026-85024: Denial of Service via Uncaught Exception in undici WebSocket Client

The undici library serves as the default, highly optimized HTTP/1.1, HTTP/2, and WebSocket client built into the Node.js runtime environment. When WebSocket connections are established with the permessage-deflate extension enabled, undici handles compression and decompression of payloads automatically. This architectural component is exposed to remote, untrusted inputs over network channels, presenting an attack surface if payload validation is bypassed or mismanaged.

CVE-2026-85024 describes a high-severity Denial of Service vulnerability within undici's WebSocket decompression logic. The vulnerability manifests during the processing of incoming binary or text frames that have been compressed using the DEFLATE algorithm. When a remote endpoint sends a payload that expands beyond configured safety thresholds, the client initiates an improper teardown of the active decompression stream.

This flaw resides in the category of uncaught exceptions (CWE-248). Due to asynchronous processing characteristics in Node.js, the premature termination of event listeners leaves the application vulnerable to delayed runtime errors. An attacker can systematically trigger this state to terminate the Node.js process, causing a complete loss of service availability.

To prevent resource exhaustion from compression attacks, such as decompression loops or zip bombs, undici enforces a maxPayloadSize constraint on decompressed frames. The library utilizes Node.js's native zlib.InflateRaw class to process compressed data streams. If the volume of decompressed bytes exceeds the limit during inflation, the library triggers a cleanup routine to discard the stream and reclaim resources.

In the vulnerable implementation, this cleanup mechanism executed this.#inflate.removeAllListeners() and set the reference to null. This call immediately detached the data, close, and error listeners from the InflateRaw instance. The design expected that the stream would cease operations immediately and be queued for garbage collection, preventing further event emission.

However, Node.js delegates native zlib operations to the libuv threadpool to run asynchronously, avoiding blocking the main JavaScript execution thread. Consequently, calling removeAllListeners() does not halt or cancel the decompression operations already queued or active within the libuv worker threads. If the input buffer contains trailing invalid DEFLATE sequences, the native decompressor continues processing and eventually encounters a Z_DATA_ERROR condition.

Because the JavaScript-level error listener was prematurely removed, the stream's subsequent error event has no registered handler. In Node.js, an unhandled error event on any EventEmitter subclass, including streams, escalates to an uncaught exception. This failure to handle the runtime error results in the immediate, non-graceful termination of the entire Node.js process.

Analyzing the vulnerable implementation in lib/web/websocket/permessage-deflate.js highlights how the stream lifecycle was mismanaged. When the decompressed output exceeded maxPayloadSize, the logic discarded the stream state without ensuring synchronous termination. The code block below represents the vulnerable implementation where listeners are detached while active work is still pending in the threadpool.

// Vulnerable Code Path
if (this.#maxPayloadSize > 0 && this.#inflate[kLength] > this.#maxPayloadSize) {
  callback(new MessageSizeExceededError())
  // Detaches the 'error' listener prematurely
  this.#inflate.removeAllListeners()
  this.#inflate = null
  return
}

The corresponding patch introduces a synchronous call to the destroy() method on the stream object. This addition ensures that the underlying native zlib context handle is immediately invalidated and freed, preventing further worker pool execution. Below is the updated and safe implementation showing the sequence of operations required to prevent late-stage error emissions.

// Patched Code Path
if (this.#maxPayloadSize > 0 && this.#inflate[kLength] > this.#maxPayloadSize) {
  callback(new MessageSizeExceededError())
  // Remove data listeners first
  this.#inflate.removeAllListeners()
  // Synchronously destroy the stream to abort threadpool operations
  this.#inflate.destroy()
  this.#inflate = null
  return
}

The integration of this.#inflate.destroy() resolves the vulnerability entirely. It provides a deterministic barrier against late-stage stream errors by immediately canceling the active zlib context. This prevents the worker thread from writing any further output or raising a Z_DATA_ERROR asynchronously, thus neutralizing the uncaught exception vector.

Exploitation of CVE-2026-85024 relies on the asymmetric nature of DEFLATE compression to construct highly efficient payload structures. An attacker must first establish or hijack a WebSocket connection with a client using an affected version of undici. The target connection must have negotiation parameters that permit the permessage-deflate extension.

To construct the attack vector, the attacker generates a payload consisting of two distinct segments. The first segment contains highly redundant data, such as a repeating sequence of null bytes, which compresses with an extremely high ratio. A payload of roughly 130 KB on the wire can decompress to exceed the default 128 MiB maxPayloadSize threshold. The second segment, placed immediately after the redundant data, consists of an invalid DEFLATE block designed to trigger a parser error.

When the client decompressor processes the first segment, the accumulated size exceeds the configured limit, triggering the cleanup sequence and removing the event listeners. The libuv worker thread then immediately encounters the trailing invalid DEFLATE bytes in the pipeline, generating a Z_DATA_ERROR. Since the error handler has been removed, the unhandled error event bubbles up to the root process, terminating the client application.

The impact of CVE-2026-85024 is classified as a complete Denial of Service (DoS) affecting the availability of the hosting application. Because undici is integrated as the default HTTP and WebSocket client in modern Node.js runtimes, any client-side WebSocket communication that connects to external, untrusted, or compromised servers is vulnerable. The vulnerability does not require authentication or specific privilege levels on the target client.

The Common Vulnerability Scoring System (CVSS) v3.1 base score of 5.9 reflects this profile. The attack vector is Network (AV:N), requiring no local access, and requires no User Interaction (UI:N). The attack complexity is rated as High (AC:H) due to the precise packet framing and sequence requirements necessary to trigger the race condition before stream destruction, though this is easily automated by an attacker.

While the scope remains Unchanged (S:U), the operational impact on production infrastructure can be severe. If the affected Node.js client has an automated reconnection policy, it will continuously re-establish the connection to the malicious endpoint and immediately crash again. This creates a loop of persistent denial of service, exhausting container orchestration resources and disrupting adjacent services.

The primary and recommended remediation is to upgrade the undici package or the Node.js runtime to a patched version. The vulnerability has been resolved in undici versions 6.28.1, 7.29.1, and 8.10.2. Upgrading to these versions or higher ensures that the destroy() method is executed synchronously upon limit detection, preventing the unhandled stream error.

If a direct package upgrade is not feasible due to transitive dependency constraints, organizations can apply package resolutions or overrides. Adding an overrides block in package.json for NPM or a resolutions block for Yarn forces all nested instances of undici to resolve to a secure version. This method mitigates the risk across all dependency trees without requiring upstream maintainers to publish updates.

{
  "overrides": {
    "undici": "^6.28.1"
  }
}

Where runtime or library updates are entirely impossible, disabling the permessage-deflate extension during the WebSocket connection negotiation serves as an effective configuration workaround. Without compressed frames, the application does not instantiate the zlib InflateRaw decompression streams, completely removing the attack vector. This can be configured by omitting the perMessageDeflate options during the client initialization phase.