Undici CVE-2026-22036: unbounded decompression chain allows resource exhaustion — patches released

What happened

• On Jan 14, 2026 the undici project published a security advisory (CVE-2026-22036 / GHSA-g9mf-h72j-4rw9): certain HTTP responses with crafted Content‑Encoding headers can create an unbounded decompression chain, allowing a malicious server to force excessive CPU work and memory allocation in clients that automatically decompress responses. Patched releases are available. (github.com)

Why full‑stack teams must care

• Undici is the de facto high-performance HTTP/1.1 client for Node.js and is used directly in many server-side services and indirectly via transitive dependencies and runtimes that bundle it. A remote server (or any upstream your service talks to) can trigger resource exhaustion in an HTTP client that blindly accepts arbitrarily long Content‑Encoding chains — this is an availability (DoS) risk for both edge servers and backend services that call third‑party APIs.
• The vulnerability affects response handling (availability), not data confidentiality. Still, availability incidents cause outages, scaling storms, and cascading failures in microservice graphs — so patching is urgent for internet‑facing and internal services that accept untrusted upstream responses.

Affected and fixed versions (short)

• Affected: undici versions < 6.23.0 and 7.0.0 <= version < 7.18.2 (see advisory for exact ranges).
• Fixed: upgrade to 6.23.0 or 7.18.2 (or a later 7.x release). (github.com)

Practical, high‑impact checklist for teams (what to do now)

1. Inventory quickly

   • Run: npm/yarn/pnpm's dependency tree check to locate undici (direct and transitive).
     • Example checks: npm ls undici || pnpm why undici.
   • Check container base images and server runtimes (some Node builds bundle undici); inspect your Docker images for vendored undici or Node images that include it.

2. Upgrade where you control the dependency

   • Direct dependency: bump undici to >= 7.18.2 (or 6.23.0 if you must stay on 6.x), then rebuild and redeploy.
   • Transitive dependency: prefer updating the top-level package that brings in undici; where not possible, use package-manager overrides (npm/yarn/pnpm) or resolution rules to force the patched undici version in your lockfile.

3. For Node runtimes that bundle undici

   • Check your Node.js release notes or vendor builds for the bundled undici version. If the bundled undici is vulnerable, upgrade Node to a security‑patched runtime from your vendor (or apply vendor guidance).
   • If you cannot immediately upgrade Node, use application-level mitigations described below.

4. Add lightweight runtime mitigations (defense‑in‑depth)

   • If you control the HTTP client code, add a decompression/response interceptor that rejects long or implausible Content‑Encoding chains (limit the number of encodings).
   • In undici, you can add an interceptor to inspect the Content‑Encoding header and reject or truncate suspicious chains before decompression runs.
   • Limit memory footprints and CPU by applying reasonable response size limits and timeouts on HTTP responses (e.g., maxHeaderSize, response timeouts) where applicable.

5. CI, containers, and orchestration

   • Ensure your CI pipeline validates the lockfile and fails if an older undici is introduced.
   • Rebuild container images and redeploy critical services on a controlled cadence (canary → rollout) to avoid rolling a breaking change widely without verification.

6. Detection and monitoring

   • Add or review run‑time metrics: CPU per-request, request latency, memory growth after outbound HTTP calls.
   • Add alarms for unexpected spikes correlated to outbound fetch calls or specific upstream hosts. Audit logs of fetch destinations during incident windows can help identify malicious upstreams.

Why this is high‑value to act on now

• This is an availability/DoS vector that can be triggered remotely by any server your code calls. Even if exploitation is moderately complex, the blast radius in microservice architectures is large: an attacker or misconfigured upstream could cause persistent high CPU/memory on many callers.
• Patching is straightforward (version upgrade or simple interceptor) and gives immediate protection; combine it with monitoring and lockfile hygiene to avoid regressions.

One‑line remediation

• Upgrade undici to a patched version (6.23.0 or >=7.18.2), rebuild images, and deploy; if you can’t immediately upgrade, add an undici interceptor to reject long Content‑Encoding chains and impose stricter response size/time limits. (github.com)

Source

• Undici security advisory: GHSA-g9mf-h72j-4rw9 (CVE‑2026‑22036). (github.com)

Source

• Source