Description

undici's decompress interceptor decompresses response bodies according to the untrusted Content-Encoding header. While the number of content-encoding layers is capped, the total decompressed output size is unbounded and there is no configuration option to limit it. A malicious or faulty upstream can therefore return a small compressed payload, a compression bomb, that expands to hundreds of megabytes or more in client memory, an asymmetric resource consumption that can exhaust memory and crash the process. This affects undici versions from 7.15.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-04T18:18:01.633Z",
  "pubdate": "2026-09-04T18:18:01.633Z",
  "executiveSummary": "The vulnerability concerns an asymmetric resource consumption flaw within the undici HTTP client's decompress interceptor. By leveraging the untrusted Content-Encoding header, an attacker can deliver a malicious, highly compressed payload that expands into a significant amount of data upon decompression.\nThe core issue is the absence of an enforced limit on the total decompressed output size of a response body. While the library enforces a cap on the number of compression layers, it fails to constrain the final buffer size in memory. This lack of resource limiting allows a malicious or compromised upstream server to trigger a denial-of-service (DoS) condition by exhausting the system memory (RAM), leading to a process crash.\nThe vulnerability affects undici versions 7.15.0 through 7.29.1 and 8.0.0 through 8.10.2. The risk profile is high, as the exploitation requirement is minimal—only the ability of the client to process a response from a malicious or faulty server. No authentication or elevated privileges are required to initiate the attack, making any application utilizing these affected versions of undici susceptible to uncontrolled memory growth and subsequent service disruption.",
  "technicalDetails": "The vulnerability originates in the logic governing the decompression process within the undici interceptor suite. When an HTTP response includes a Content-Encoding header (such as gzip or br), the client attempts to decompress the body stream before passing it to the application layer. The implementation is designed to handle multiple compression layers, for which it correctly implements a counter to prevent recursive 'zip bomb' structures that involve excessive nested headers.\nHowever, the implementation lacks a mechanism to monitor or throttle the actual byte count of the output stream generated during the decompression process. Because the expansion ratio of compressed data can be massive, a relatively small payload of a few kilobytes can be crafted to expand into hundreds of megabytes or even gigabytes of raw data. Since undici buffers the decompressed response in memory to fulfill the request, the process's heap allocation grows proportionally to the decompressed size.\nThe attack flow follows a straightforward progression: 1) The attacker initiates an HTTP request (or serves as a malicious upstream server); 2) The undici client receives a response containing the Content-Encoding header; 3) The decompress interceptor begins processing the stream, recursively decompressing the layers; 4) The interceptor writes the decompressed stream into the process memory without verifying the cumulative output size; 5) As the buffer expands, the Node.js process experiences rapid memory exhaustion (Out-of-Memory event), leading to a crash and service unavailability.\nThis vulnerability is classified as an asymmetric resource consumption issue because the attacker provides minimal input to cause maximal impact on the target's system resources. The lack of an configurable limit means that the application developer cannot implement protective measures within the undici configuration, leaving the process fully exposed to memory pressure until the heap limit is reached. The flaw persists in versions 7.15.0 to 7.29.1 and 8.0.0 to 8.10.2, and it represents a critical risk to the stability of any microservices or applications that rely on undici to fetch data from untrusted or potentially compromised third-party endpoints."
}