GHSA-3xpg-4rpp-hhhm: Medium severity npm/undici vulnerability
Impact
The interceptors.decompress() interceptor decompresses HTTP response bodies according to the untrusted Content-Encoding header. The number of decompression layers is capped at 5, but the total decompressed output size is not bounded and there is no option to limit it. A malicious or faulty upstream can return a small compressed payload (a compression bomb) that expands to hundreds of megabytes or gigabytes in client memory, exhausting memory and causing the Node.js process to crash or become unresponsive. Any application using the decompress interceptor to read responses from untrusted or compromised upstreams is affected.
Patches
Upgrade to 7.29.1 or 8.10.2. The interceptor now accepts a maxSize option (default 64 MiB) and rejects responses whose decompressed output exceeds it with a ResponseExceededMaxSizeError.
Workarounds
Once upgraded, set a conservative maxSize on the interceptor. Before upgrading, avoid using interceptors.decompress() with untrusted upstreams, or apply a custom interceptor that enforces a decompressed output size limit.
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.10.2 - Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 7.29.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.29.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.10.2 - Configuration
Set a conservative maxSize for decompressed output; the interceptor default is 64 MiB and responses exceeding the limit are rejected.
interceptors.decompress() maxSize = 64 MiB - Compensating control
Before upgrading, avoid using interceptors.decompress() with untrusted upstreams, or use a custom interceptor that enforces a decompressed output size limit.
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Applications using the `interceptors.decompress()` interceptor to read HTTP responses from untrusted or compromised upstreams are affected. A malicious or faulty upstream can send a small compressed response that expands until the Node.js process exhausts memory.
Does exploitation require authentication or user interaction?
No. The supplied vector lists network access with no privileges or user interaction required, though exploitation has high attack complexity. The attacker needs to control, compromise, or otherwise cause a targeted upstream to return a compression bomb with a `Content-Encoding` header.
What changes after upgrading, and how should the limit be configured?
Upgrade to `7.29.1` or `8.10.2`, where the interceptor supports `maxSize` and defaults it to 64 MiB. Set `maxSize` to a conservative value appropriate for the application; oversized decompressed responses are rejected with `ResponseExceededMaxSizeError`.
What can be done if an upgrade cannot be applied immediately?
Do not use `interceptors.decompress()` for responses from untrusted upstreams. Alternatively, use a custom interceptor that enforces a limit on the decompressed output size.