CVE-2026-29057 in next.js
Summary
by MITRE • 03/18/2026
Next.js is a React framework for building full-stack web applications. Starting in version 9.5.0 and prior to versions 15.5.13 and 16.1.7, when Next.js rewrites proxy traffic to an external backend, a crafted `DELETE`/`OPTIONS` request using `Transfer-Encoding: chunked` could trigger request boundary disagreement between the proxy and backend. This could allow request smuggling through rewritten routes. An attacker could smuggle a second request to unintended backend routes (for example, internal/admin endpoints), bypassing assumptions that only the configured rewrite destination/path is reachable. This does not impact applications hosted on providers that handle rewrites at the CDN level, such as Vercel. The vulnerability originated in an upstream library vendored by Next.js. It is fixed in Next.js 15.5.13 and 16.1.7 by updating that dependency’s behavior so `content-length: 0` is added only when both `content-length` and `transfer-encoding` are absent, and `transfer-encoding` is no longer removed in that code path. If upgrading is not immediately possible, block chunked `DELETE`/`OPTIONS` requests on rewritten routes at the edge/proxy, and/or enforce authentication/authorization on backend routes.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/23/2026
The vulnerability identified as CVE-2026-29057 affects Next.js applications built using versions 9.5.0 through 15.5.12 and 16.1.6, presenting a significant security risk through request smuggling attacks. This flaw emerges from the framework's handling of proxy traffic when rewriting requests to external backends, creating a scenario where malicious actors can manipulate HTTP request boundaries between the proxy and backend servers. The vulnerability specifically targets the processing of DELETE and OPTIONS requests that utilize Transfer-Encoding: chunked header, exploiting a fundamental disagreement in how request boundaries are interpreted by the proxy versus the backend system. The security implications extend beyond simple data exposure, as attackers can potentially smuggle requests to unintended backend routes, including internal or administrative endpoints that should remain protected from external access. This vulnerability directly relates to CWE-444, which addresses HTTP request smuggling, and aligns with ATT&CK technique T1190, covering exploit for lateral movement through web application vulnerabilities. The issue stems from an upstream library dependency that Next.js vendors, indicating that the root cause lies outside the core framework itself but manifests through Next.js's implementation of proxy handling. Applications hosted on platforms like Vercel remain unaffected since these providers manage rewrites at the CDN level rather than within the application's proxy configuration.
The technical mechanism behind this vulnerability involves the improper handling of HTTP headers during request proxying, specifically when both Content-Length and Transfer-Encoding headers are present or absent. The flaw occurs in the logic that determines when to add a content-length: 0 header, which should only be added when both Content-Length and Transfer-Encoding are completely absent from the request. However, the vulnerable code path was removing Transfer-Encoding headers before applying the content-length: 0 logic, creating inconsistency in how the request boundary is interpreted by different systems in the communication chain. This inconsistency enables attackers to craft requests that appear valid to the proxy but are interpreted differently by the backend, allowing the smuggling of additional requests that bypass normal access controls and routing restrictions. The vulnerability represents a sophisticated attack vector because it leverages the fundamental HTTP protocol mechanics to create a communication gap that can be exploited to access restricted resources. When combined with the fact that Next.js applications often handle sensitive internal routes through rewrites, this creates a pathway for attackers to reach administrative endpoints that should only be accessible through authenticated and authorized channels.
The operational impact of this vulnerability extends beyond immediate data exposure to include potential privilege escalation and system compromise through unauthorized access to backend services. Attackers exploiting this vulnerability could gain access to internal administrative interfaces, configuration endpoints, or other sensitive backend resources that are typically protected by network segmentation or access controls. The vulnerability is particularly concerning for applications that rely on Next.js rewrites to access internal services, as these routes become potential entry points for attackers seeking to escalate privileges or extract sensitive information. Organizations using vulnerable Next.js versions face a heightened risk of data breaches, especially in environments where internal services lack proper authentication mechanisms or where rewrites are used to expose services without appropriate security controls. The attack surface is further expanded because the vulnerability can be exploited through seemingly benign HTTP methods like DELETE and OPTIONS, which are commonly used in legitimate application operations but can be weaponized for malicious purposes. This makes detection particularly challenging as the malicious requests may appear as normal application traffic to security monitoring systems.
Mitigation strategies for CVE-2026-29057 should prioritize immediate remediation through version upgrades to Next.js 15.5.13 or 16.1.7, which contain the necessary dependency updates that address the core logic flaw. When immediate upgrades are not feasible, organizations should implement defensive measures at the edge or proxy level to block chunked DELETE and OPTIONS requests on rewritten routes, effectively preventing the vulnerable code path from being triggered. Additional protective measures include enforcing strict authentication and authorization controls on all backend routes, particularly those that are accessible through rewrites, ensuring that even if smuggling occurs, unauthorized access remains impossible. Network-level controls should be implemented to monitor and restrict access to internal endpoints, while application-level security measures should validate all incoming requests and implement proper input sanitization to prevent exploitation. Organizations should also conduct comprehensive security assessments of their Next.js applications to identify all rewrite configurations that might be vulnerable, and implement automated monitoring for suspicious request patterns that could indicate exploitation attempts. The fix implemented in the patched versions addresses the root cause by ensuring that content-length: 0 is only added when both Content-Length and Transfer-Encoding headers are absent, and prevents the removal of Transfer-Encoding headers in the specific code path where the vulnerability existed. This approach aligns with security best practices for HTTP request handling and prevents the boundary disagreement that enables request smuggling attacks.