CVE-2026-1525

What it actually does

The flaw is an improper input validation issue in Node.js Undici where low-level request APIs can emit multiple HTTP/1.1 Content-Length headers if headers are supplied as a flat array with case-variant names such as Content-Length and content-length. Because HTTP header names are case-insensitive, these should be treated as duplicates, but the vulnerable behavior can place conflicting Content-Length values on the wire. Strict HTTP parsers may reject the request, causing application errors or denial of service. In more complex proxy-to-backend architectures, inconsistent interpretation of duplicate Content-Length headers can create HTTP request smuggling conditions, potentially allowing an attacker to desynchronize an intermediary and backend server.

Why it matters to the business

Applications that use Undici for outbound HTTP requests may fail when communicating through strict proxies, API gateways, load balancers, or servers, resulting in broken integrations, failed transactions, and degraded service availability. Where user-controlled header names are passed into Undici without normalization, the issue can become a security boundary bypass risk: attackers may be able to manipulate downstream request parsing, poison caches, bypass access controls, or interfere with other users' requests. The vulnerability is not currently listed in CISA KEV, has no reported mature exploitation, and has a low EPSS score, but it should still be prioritized for internet-facing services, API gateways, SSRF-prone request-forwarding features, and systems that accept or transform user-supplied HTTP headers.

How an attack unfolds

An attacker first identifies an application feature that uses Undici low-level APIs such as undici.request() or undici.Client to construct outbound HTTP/1.1 requests. The attacker then supplies or influences request headers so that two Content-Length headers are included with different casing, for example Content-Length and content-length, and potentially with conflicting numeric values. In vulnerable cases, Undici serializes both headers rather than normalizing and rejecting the duplicate. If the request reaches a strict parser, the request may be rejected, causing application errors or denial of service. If the request passes through a proxy, gateway, cache, or load balancer that interprets duplicate Content-Length headers differently from the backend, the attacker may craft the body so the intermediary and backend disagree about where one request ends and the next begins. That desynchronization can be used for HTTP request smuggling outcomes such as routing a hidden request, poisoning a cache entry, bypassing frontend controls, or affecting another user's connection.

How to fix it

Upgrade Undici to a version that fixes duplicate case-variant Content-Length handling when a patched version is available from the Node.js/Undici maintainers. If Undici is bundled through Node.js or another framework, update the parent runtime or dependency package that includes the fixed Undici release. In the meantime, normalize all outbound header names to lowercase before passing them to Undici, reject duplicate case-insensitive header names, and never allow untrusted users to supply hop-by-hop or framing headers such as Content-Length, Transfer-Encoding, Connection, Host, Upgrade, and Trailer. Prefer high-level APIs that validate headers safely, avoid flat-array header construction where possible, and enforce a single authoritative Content-Length generated by the HTTP client. At proxies, gateways, and backends, reject requests containing duplicate Content-Length headers and ensure consistent HTTP request parsing behavior across all tiers.

How to confirm the fix worked

Review dependency manifests and lockfiles for vulnerable Undici versions, including direct use of the undici package and transitive copies bundled by frameworks or Node.js tooling. Search application code for undici.request(), new Client(), Pool, Dispatcher, or similar low-level APIs where headers are passed as arrays. Confirm that header names are normalized case-insensitively and duplicates are rejected before requests are sent. In a non-production test environment, attempt to send a request through the application with both Content-Length and content-length headers containing different values and verify that the application rejects the input before Undici serializes it. Also validate that upstream proxies, API gateways, and backends reject duplicate Content-Length requests consistently and do not forward them to backend services.

Typical attack path

1. Find an application endpoint or workflow that forwards attacker-influenced HTTP requests using Node.js Undici low-level APIs.
2. Provide duplicate Content-Length headers using different casing, such as Content-Length and content-length, usually with conflicting values.
3. Cause the vulnerable Undici client to serialize both headers into the outbound HTTP/1.1 request.
4. Send the malformed request through a proxy, gateway, load balancer, cache, or backend server.
5. Trigger request rejection for denial of service, or exploit parser inconsistencies between intermediary and backend systems.
6. Use request desynchronization to attempt ACL bypass, cache poisoning, credential exposure, or interference with subsequent requests.

How to detect it

Look for evidence of malformed HTTP requests containing duplicate Content-Length headers with different casing or conflicting values. Useful log sources include application logs from Node.js services, reverse proxy logs, API gateway logs, WAF events, load balancer logs, backend web server access/error logs, and packet captures from egress traffic generated by affected applications. Search for spikes in 400 Bad Request, HPE_UNEXPECTED_CONTENT_LENGTH, duplicate Content-Length, invalid Content-Length, request smuggling, HTTP desync, upstream prematurely closed connection, or similar parser errors. Correlate these events with application routes that accept custom headers, proxy requests, relay webhooks, fetch user-supplied URLs, or transform inbound requests into outbound Undici calls. In forensic packet captures, inspect outbound HTTP/1.1 requests from Node.js services for multiple Content-Length header lines, especially case variants such as Content-Length and content-length. Because exploitation may only leave parser errors or anomalous proxy/backend behavior, also review cache anomalies, unexpected backend route hits, unusual 4xx bursts, and mismatches between frontend and backend request logs around the same connection or timestamp.

• Content-Length:
• content-length:
• HPE_UNEXPECTED_CONTENT_LENGTH
• Duplicate Content-Length
• duplicate Content-Length
• multiple Content-Length
• invalid Content-Length
• conflicting Content-Length
• 400 Bad Request
• HTTP request smuggling
• HTTP desync
• request desynchronization
• upstream prematurely closed connection
• client sent invalid header line
• client sent duplicate header line
• Content-Length and Transfer-Encoding

What your security team should do

• Inventory applications using Node.js Undici, especially those using low-level APIs and custom header forwarding logic.
• Prioritize review of internet-facing request-forwarding services, API gateways, webhook relays, SSRF-prone fetchers, and applications that accept user-controlled headers.
• Patch Undici or the parent Node.js/framework dependency as soon as a fixed version is available, then redeploy affected services.
• Add defensive validation that lowercases header names and rejects duplicate case-insensitive headers before outbound requests are created.
• Block or strip user-supplied Content-Length, Transfer-Encoding, Connection, Host, Upgrade, Trailer, and other HTTP framing or hop-by-hop headers.
• Configure proxies, gateways, WAFs, and origin servers to reject duplicate Content-Length headers and inconsistent Content-Length/Transfer-Encoding combinations.
• Add logging for rejected duplicate HTTP framing headers and monitor for repeated attempts, which may indicate request smuggling probing.
• Perform targeted testing for HTTP request smuggling behavior across proxy-to-backend paths that handle traffic generated by affected applications.