CVE-2026-87029: undici vulnerable to Denial of Service via unhandled exception in the decompress interceptor
Impact
undici's decompress interceptor forwards decompressed response data to the downstream handler from zlib stream event callbacks without catching exceptions those callbacks may throw. undici's engine converts a synchronous throw from a downstream handler into a per-request failure, but that protection is not in place when the throw happens asynchronously from a zlib callback. As a result, a downstream handler that throws by design, for example the built-in dump interceptor which throws when a response exceeds its maxSize, escapes as an uncaught exception and terminates the Node.js process.
A malicious or compromised HTTP server can crash any client that composes the decompress interceptor with dump (or another response handler that throws), by returning a small compressed body that decompresses to more than the configured limit. The compressed bytes on the wire are tiny, so only the decompressed size matters. If the application keeps the process alive with a global uncaught-exception handler, the affected request instead hangs until the body timeout.
Patches
Upgrade to undici 7.30.1 or 8.12.2.
Workarounds
Avoid composing the decompress interceptor with a response handler that throws during response processing (such as dump with a maxSize) until upgrading.
Other sources
undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its decompress interceptor forwards decompressed response data to the downstream handler from zlib stream event callbacks without catching exceptions those callbacks may throw, and while undici's engine converts a synchronous throw from a downstream handler into a per-request failure, that protection is absent when the throw happens asynchronously from a zlib callback. As a result, a downstream handler that throws by design, such as the built-in dump interceptor which throws when a response exceeds its configured maximum size, escapes as an uncaught exception that terminates the Node.js process. A malicious or compromised HTTP server can crash any client that composes the decompress interceptor with such a handler by returning a small compressed body that decompresses to more than the configured limit, so only the decompressed size matters and the bytes on the wire stay tiny. The issue is fixed in undici 7.30.1 and 8.12.2, and users should upgrade to one of those versions or later. As a workaround, avoid composing the decompress interceptor with a response handler that throws during response processing until upgrading.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 8.12.2 - Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 7.30.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 7.30.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 8.12.2 - Compensating control
Avoid composing the decompress interceptor with a response handler that throws during response processing, such as dump with a maxSize, until upgrading.
Event History
Frequently Asked Questions
Which applications are exposed to this denial-of-service issue?
Applications using undici versions 7.15.0 through 7.30.0 or 8.0.0 through 8.12.1 are exposed when they compose the decompress interceptor with a downstream response handler that can throw. A built-in example is the dump interceptor when a response exceeds its configured maximum size.
What must an attacker control to trigger the crash?
An attacker needs a malicious or compromised HTTP server that the affected client requests. The server can return a small compressed response that expands beyond the downstream handler's configured limit, causing an uncaught exception and terminating the Node.js process.
Are all uses of the decompress interceptor affected?
The described crash requires the decompress interceptor to be composed with a downstream handler that throws from the zlib callback path. The issue is specifically triggered when decompressed response data causes such a handler to throw.
What can be done if upgrading is not immediately possible?
Avoid composing the decompress interceptor with a response handler that throws. Upgrading to undici 7.30.1, 8.12.2, or later fixes the issue.