CVE-2026-84890

What it actually does

undici's decompress interceptor honors the untrusted Content-Encoding header and inflates response bodies without a bound on total decompressed size. Layer count is capped, but a small compressed payload can expand to hundreds of megabytes or more in process memory, causing asymmetric allocation, heap exhaustion, and crash of the Node.js process. Confidentiality and integrity are unaffected; availability of the consuming process is fully at risk. Affected undici lines are 7.15.0 through versions before 7.29.1 and 8.0.0 through versions before 8.10.2.

Why it matters to the business

Services that fetch HTTP resources with undici (including many Node.js applications, Grafana, and Red Hat Node.js 24/26 stacks) can be taken offline by a malicious or faulty upstream, producing outages, failed background jobs, and cascading restarts. There is no KEV listing, no ransomware association, and exploit maturity is none about 30 days after publication, so mass in-the-wild abuse is not indicated—but undici is the default Node.js HTTP client, so a single unpatched dependency can still halt customer-facing APIs, telemetry pipelines, and plugin/data-source fetches. Operational cost is unplanned downtime and incident response rather than data theft.

How an attack unfolds

An attacker who can influence an HTTP response consumed by undici—by operating a malicious origin, compromising an upstream API, or steering the client via redirect or attacker-controlled URL—returns a small body with a supported Content-Encoding (for example gzip, deflate, or brotli) that expands enormously when inflated. The client applies the decompress interceptor, allocates unbounded output, and the process dies from memory exhaustion. High attack complexity in the CVSS vector reflects the need to be, or to control, that upstream and for decompression to be in the request path. No named APT groups or campaigns are associated, and no public exploit maturity is reported.

How to fix it

Upgrade undici to 7.29.1 (7.x line) or 8.10.2 (8.x line), which are the vendor-fixed releases. On Red Hat-packaged products apply RHSA-2026:54389: grafana12-4-main to 12.4.10-0.2.hum1, nodejs24-main to 11.16.0-1.24.18.1.0.2.2.hum1, and nodejs26-main to 26.7.0-1.5.2.hum1. Rebuild and redeploy any containers or lockfiles that pin undici below those versions. Until patched, avoid fetching untrusted origins with automatic decompression, restrict outbound HTTP to known-good hosts, and impose process-level memory limits and restart budgets so a single bomb cannot take down the whole node. There is no documented configuration switch in affected releases to cap decompressed output size.

How to confirm the fix worked

Confirm package metadata shows undici 7.29.1, 8.10.2, or later (npm ls undici, lockfile, and image SBOM). On Red Hat, verify the RHSA-2026:54389 package NVRs above are installed. After upgrade, exercise outbound fetches that return Content-Encoding compressed bodies and confirm the process neither grows without bound nor crashes. Inventory all services that depend on undici transitively (Grafana data sources, Node 24/26 runtimes, and app lockfiles) and treat any remaining 7.15.0–<7.29.1 or 8.0.0–<8.10.2 install as exposed.

Typical attack path

1. Identify an application or service whose outbound HTTP client is undici with the decompress interceptor enabled.
2. Arrange for that client to request a URL the attacker controls or can poison (malicious origin, compromised API, or attacker-chosen redirect/target).
3. Return an HTTP response whose Content-Encoding advertises a supported compression scheme and whose body is a compact, highly compressible payload (a compression bomb).
4. Wait for undici to decode the body into an unbounded in-memory buffer.
5. Observe client heap growth, event-loop stall, or process crash, repeating as needed against auto-restarting workers to sustain denial of service.

How to detect it

Look for Node.js processes that died from heap exhaustion shortly after an outbound HTTP response with Content-Encoding gzip, deflate, or br, especially when the on-wire body was small relative to subsequent RSS/heap growth. Review application and container logs around OOM kills, undici/dispatcher stack frames, and supervisor restart storms. Network or proxy logs showing a trusted client suddenly pulling a tiny compressed object from a new or unusual origin are useful correlation points. No named threat actors are tied to this CVE, so hunt on the resource-exhaustion pattern rather than actor-specific tooling. Artifact sources: Node fatal logs, systemd/journald OOM, Kubernetes OOMKilled, APM memory metrics, and HTTP access/proxy logs for Content-Encoding and content-length mismatch.

• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• ERR_WORKER_OUT_OF_MEMORY
• Content-Encoding: gzip
• Content-Encoding: deflate
• Content-Encoding: br
• undici:decompress
• OOMKilled
• nodejs.*heap out of memory

What your security team should do

• Patch undici to 7.29.1 or 8.10.2, and apply RHSA-2026:54389 on Grafana 12.4 and Node.js 24/26 images, as the primary fix.
• Enumerate lockfiles, containers, and language runtimes that ship undici and block builds that still pin vulnerable ranges.
• Until rollout completes, constrain outbound HTTP to trusted origins and set cgroup/container memory limits plus crash-loop alerts on Node processes.
• Because this is not in KEV and exploit maturity is none, prioritize by internet-facing fetchers and multi-tenant workers first, then remaining internal clients within normal patch SLAs.
• Add regression tests that compressed responses cannot inflate past an application-defined budget after the upgrade.