Undici has an unbounded decompression chain in HTTP responses on Node.js Fetch API via Content-Encoding leads to resource exhaustion
Published 14 Jan 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=7.0.0 <7.18.2
- Fixed in
- 7.18.2
npm install undici@7.18.2- Affected
- <6.23.0
- Fixed in
- 6.23.0
npm install undici@6.23.0Details
Impact
The fetch() API supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., Content-Encoding: gzip, br). This is also supported by the undici decompress interceptor.
However, the number of links in the decompression chain is unbounded and the default maxHeaderSize allows a malicious server to insert thousands compression steps leading to high CPU usage and excessive memory allocation.
Patches
Upgrade to 7.18.2 or 6.23.0.
Workarounds
It is possible to apply an undici interceptor and filter long Content-Encoding sequences manually.
References
- https://hackerone.com/reports/3456148
- https://github.com/advisories/GHSA-gm62-xv2j-4w53
- https://curl.se/docs/CVE-2022-32206.html
Is GHSA-g9mf-h72j-4rw9 in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected undici, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.