undici is vulnerable to Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Vulnerability

CVE-2026-1525 describes a flaw in the Undici HTTP client for Node.js where duplicate Content-Length headers are not rejected when provided as an array with case-variant names (e.g., Content-Length and content-length). This violates RFC 9110 Section 8.6, which mandates that HTTP messages must not contain multiple Content-Length header fields with different values [1]. The root cause is the absence of case-normalization when processing header arrays, leading to malformed HTTP/1.1 requests on the wire.

Exploitation

An attacker who can control the headers passed to undici.request(), undici.Client, or similar low-level APIs can supply an array containing both Content-Length and content-length with differing values. No authentication is required if the application accepts user-supplied header names without sanitization. The attack surface includes any application that uses flat header arrays and does not normalize header names before passing them to Undici.

Impact

Strict HTTP parsers (proxies, servers) will reject the malformed request with a 400 Bad Request, causing a denial of service. More critically, in deployments where an intermediary and backend interpret duplicate headers inconsistently (e.g., one uses the first value, the other uses the last), this can enable HTTP request smuggling attacks [2]. Such smuggling may lead to ACL bypass, cache poisoning, or credential hijacking, as described in CWE-444 [2].

Mitigation

As of the publication date, no patch has been announced. Users should normalize header names to a consistent case before passing them to Undici, or avoid using flat arrays for user-controlled headers. Applications should also validate that Content-Length appears at most once. The Undici project is aware of the issue [3] and a fix is expected in a future release.