CVE-2026-29057

What it actually does

CVE-2026-29057 is a request smuggling flaw in self-hosted Next.js applications using rewrites that proxy traffic to an external backend. In affected versions starting with 9.5.0 and before 15.5.13 or 16.1.7, crafted DELETE or OPTIONS requests using `Transfer-Encoding: chunked` can cause the Next.js rewrite proxy and the destination backend to disagree about where one HTTP request ends and the next begins. Because of that boundary mismatch, an unauthenticated network attacker may be able to embed a second HTTP request inside the first one and have the backend process it as a separate request to an unintended route, such as an internal or administrative endpoint. The issue is tied to how a vendored upstream dependency handled `content-length` and `transfer-encoding` headers. Applications where rewrites are handled at the CDN layer, such as Vercel-hosted applications, are not impacted by this specific proxy behavior.

Why it matters to the business

Successful exploitation could let an external attacker reach backend paths that application owners assumed were not reachable through the public rewrite route. Depending on backend authorization controls, this may expose internal functions, administrative endpoints, sensitive data, or state-changing operations. The CVSS score is moderate at 6.5 and EPSS is currently low at 0.00427, with no CISA KEV listing and no known ransomware association, so this is not presently a mass-exploitation emergency; however, the vulnerability is remotely reachable, requires no authentication, and affects a widely used web framework, so internet-exposed self-hosted Next.js deployments that proxy rewrites to external backends should be remediated promptly.

How an attack unfolds

An attacker first identifies a self-hosted Next.js application that uses rewrite rules to forward requests from a public route to an external backend. The attacker then sends a specially crafted DELETE or OPTIONS request to the rewritten route with `Transfer-Encoding: chunked` and a request body designed so that the Next.js rewrite proxy and the backend interpret the request boundary differently. The visible request appears to target the allowed rewritten route, but the crafted body contains a second HTTP request aimed at another backend path. If the backend accepts the smuggled request on the reused connection, it may process that hidden request as if it were legitimate traffic from the proxy. Impact depends heavily on backend routing and authorization: strong backend authorization may limit the result, while backend endpoints that rely on network location, proxy path restrictions, or rewrite assumptions may be exposed.

How to fix it

Upgrade affected Next.js applications to a fixed version: Next.js 15.x should be upgraded to 15.5.13 or later, and Next.js 16.x should be upgraded to 16.1.7 or later. For older release lines, migrate to a supported fixed release. After upgrading, rebuild and redeploy the application so the corrected vendored dependency behavior is active. If immediate upgrade is not possible, block requests that combine DELETE or OPTIONS methods with `Transfer-Encoding: chunked` on routes that are handled by Next.js rewrites, preferably at the CDN, edge proxy, WAF, load balancer, or ingress layer. Also ensure backend services enforce authentication and authorization independently of the frontend rewrite path; backend administrative or internal routes should not trust that they are unreachable through the proxy. Where feasible, avoid proxying sensitive backend services through generic public rewrite rules.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.13 or later for the 15.x line, 16.1.7 or later for the 16.x line, or otherwise not in the affected range starting from 9.5.0. Validate the running artifact, not only source manifests, by checking the built container image, package lockfile, deployment logs, or runtime package metadata. Review application configuration for Next.js `rewrites` entries that proxy to external origins and confirm compensating controls exist if any affected version remains deployed. Send safe negative tests in a non-production or controlled environment to verify that DELETE and OPTIONS requests with `Transfer-Encoding: chunked` are rejected or normalized before reaching rewritten backend routes. Confirm backend access controls by directly testing that sensitive routes require authentication and authorization even when traffic arrives through the application proxy path.

Typical attack path

1. Identify a public Next.js application that is self-hosted rather than relying on CDN-level rewrites.
2. Find routes that use Next.js rewrites to proxy traffic to an external backend service.
3. Send probe requests using DELETE or OPTIONS with `Transfer-Encoding: chunked` to test for parser or request-boundary inconsistencies.
4. Craft a chunked request whose payload contains a second HTTP request targeting an unintended backend route.
5. Deliver the request to the rewritten route so the proxy forwards traffic to the backend connection.
6. Cause the backend to interpret the embedded payload as a separate request.
7. Attempt access to internal, administrative, or otherwise unintended backend endpoints.
8. Use any successful response or side effect to read data, invoke privileged functions, or bypass routing assumptions.

How to detect it

Investigate HTTP access logs from the public web tier, CDN or edge proxy, WAF, ingress controller, Next.js server, and destination backend services. Focus on DELETE and OPTIONS requests to routes known to be handled by Next.js rewrites, especially when the request includes `Transfer-Encoding: chunked`, unusual body content, malformed chunk framing, duplicate or conflicting HTTP framing headers, or unexpected backend responses. Correlate frontend requests with backend logs to find cases where one client request appears to result in an additional backend request, a request to an unadvertised internal/admin route, or backend activity without a corresponding normal frontend request. Look for spikes in 400, 408, 411, 413, 502, or 504 responses around rewritten routes, as these can indicate probing for request smuggling behavior. Review backend logs for access to sensitive paths shortly after chunked DELETE or OPTIONS requests from the same source IP or connection. If packet captures or full request logging are available, inspect raw HTTP framing for embedded request lines such as `GET /admin`, `POST /internal`, or other second requests appearing inside a chunked request body. There are no public reports of KEV exploitation or named threat actor use in the supplied data, so detection should focus on behavioral evidence rather than actor-specific infrastructure.

• Transfer-Encoding: chunked
• DELETE
• OPTIONS
• content-length: 0
• Content-Length: 0
• GET /admin
• POST /admin
• GET /internal
• POST /internal
• GET /api/admin
• POST /api/admin
• GET /_next
• DELETE /_next
• OPTIONS /_next
• HTTP/1.1 400
• HTTP/1.1 411
• HTTP/1.1 502

What your security team should do

• Inventory self-hosted Next.js applications and identify those using rewrite rules to proxy traffic to external backends.
• Prioritize remediation for internet-facing deployments, especially where rewritten routes lead to APIs, administrative services, or internal backends.
• Upgrade to Next.js 15.5.13, 16.1.7, or later and redeploy all affected applications.
• If upgrade cannot be completed quickly, add edge, WAF, ingress, or reverse-proxy rules to block chunked DELETE and OPTIONS requests on rewritten routes.
• Review backend services behind rewrites and enforce authentication and authorization at the backend rather than relying on route obscurity or proxy path constraints.
• Search historical web, proxy, WAF, and backend logs for suspicious chunked DELETE or OPTIONS requests and unusual access to internal/admin paths through rewrite destinations.
• Add monitoring for malformed HTTP requests, request smuggling probes, backend 400/502 anomalies, and unexpected administrative endpoint hits following DELETE or OPTIONS traffic.
• Track vendor advisories and dependency updates because the vulnerable behavior originated in a vendored upstream library.