CVE-2026-29057 is a vulnerability classified under CWE-444 (Inconsistent Interpretation of HTTP Requests), commonly known as HTTP request smuggling. It affects the Next.js React framework versions starting from 9.5.0 up to versions prior to 15.5.13 and 16.1.7. The vulnerability occurs specifically when Next.js rewrites proxy traffic to an external backend server. An attacker can craft DELETE or OPTIONS HTTP requests with the Transfer-Encoding: chunked header to induce a disagreement between the proxy and backend server about where one HTTP request ends and another begins. This discrepancy enables the attacker to smuggle a second HTTP request through the rewritten route, potentially reaching backend endpoints that should be inaccessible, such as internal or administrative routes. The root cause lies in an upstream library vendored within Next.js that mishandles the addition and removal of content-length and transfer-encoding headers during request rewriting. The fix implemented in Next.js versions 15.5.13 and 16.1.7 updates this behavior to add content-length: 0 only when both content-length and transfer-encoding headers are absent, and to avoid removing transfer-encoding in the vulnerable code path. Applications hosted on platforms that perform rewrites at the CDN level, like Vercel, are not impacted. If immediate upgrading is not feasible, recommended mitigations include blocking chunked DELETE and OPTIONS requests on rewritten routes at the edge or proxy level, and enforcing strict authentication and authorization on backend routes to prevent unauthorized access. The CVSS 4.0 base score is 6.3, indicating a medium severity, with network attack vector, low complexity, no privileges required, no user interaction, and partial impact on confidentiality and integrity. There are no known exploits in the wild as of the publication date.

This vulnerability allows attackers to bypass route restrictions by smuggling additional HTTP requests to backend endpoints that are not intended to be accessible via the rewritten routes. This can lead to unauthorized access to sensitive internal or administrative interfaces, potentially exposing confidential data or enabling further exploitation. The inconsistent interpretation of HTTP requests between proxy and backend can undermine application security assumptions, leading to integrity violations and partial confidentiality breaches. Since the attack requires no authentication or user interaction and can be executed remotely over the network, the attack surface is broad for affected Next.js applications that perform proxy rewrites. Organizations using vulnerable Next.js versions in their web applications risk unauthorized access, data leakage, and potential compromise of backend services. However, applications hosted on providers that handle rewrites at the CDN level, such as Vercel, are not affected, reducing risk for those deployments. The absence of known active exploits reduces immediate risk but does not eliminate the threat, especially as exploit techniques for HTTP request smuggling are well understood and can be weaponized.

1. Upgrade Next.js to version 15.5.13 or later, or 16.1.7 or later, which include the fix for this vulnerability by correcting the handling of content-length and transfer-encoding headers during proxy rewrites. 2. If upgrading is not immediately possible, implement edge or proxy-level controls to block HTTP DELETE and OPTIONS requests that use Transfer-Encoding: chunked on rewritten routes to prevent smuggling attempts. 3. Enforce strict authentication and authorization on all backend routes, especially internal and administrative endpoints, to limit access even if request smuggling occurs. 4. Conduct thorough security testing, including HTTP request smuggling tests, on applications using Next.js proxy rewrites to detect potential exploitation paths. 5. Monitor web server and application logs for anomalous or malformed HTTP requests indicative of request smuggling attempts. 6. Consider deploying Web Application Firewalls (WAFs) with rules specifically designed to detect and block HTTP request smuggling techniques. 7. For deployments on cloud or CDN providers, verify that rewrites are handled at the CDN or edge level, which mitigates this vulnerability inherently. 8. Educate development and operations teams about the risks of HTTP request smuggling and secure proxy configuration best practices to prevent similar issues.