CVE-2026-44572

What it actually does

The flaw affects Next.js middleware/proxy redirect handling in versions 12.2.0 through versions before 15.5.16 and 16.2.5. An unauthenticated remote client can add the `x-nextjs-data` request header to a normal browser-style request for a route handled by middleware that returns a redirect. Under vulnerable conditions, Next.js treats the request like an internal data request and emits `x-nextjs-redirect` instead of the standard HTTP `Location` header. Browsers do not honor `x-nextjs-redirect` as a redirect target. If a CDN, edge cache, or reverse proxy stores the resulting 3xx response without varying the cache key on `x-nextjs-data`, the malformed redirect can be served to later users, causing denial of service for the affected redirecting path until cache expiry or purge.

Why it matters to the business

An attacker may be able to make selected redirecting pages or flows stop working for normal visitors, such as login redirects, locale redirects, marketing redirects, onboarding paths, or other middleware-controlled routes. The impact is availability-focused rather than data theft or code execution, but it can still disrupt user access, conversion funnels, authentication flows, and customer-facing web traffic. Risk is highest for public Next.js applications behind CDNs or reverse proxies that cache 3xx responses and do not include the `x-nextjs-data` header in cache variation. The CVSS and EPSS values indicate low severity and currently low exploitation likelihood, and it is not listed in CISA KEV; however, internet-facing applications with aggressive edge caching can be affected by a single crafted request to a cacheable redirect path.

How an attack unfolds

An attacker first identifies a public Next.js application and locates a route handled by middleware or proxy logic that returns an HTTP redirect. The attacker then sends a normal request to that route but includes the `x-nextjs-data` header, causing vulnerable Next.js versions to process the request as if it were a data request. Instead of returning a normal redirect with a `Location` header, the response may contain `x-nextjs-redirect`. If an upstream CDN or reverse proxy caches that 3xx response and does not vary the cached object based on the presence or value of `x-nextjs-data`, the malformed redirect response can become the cached version for that URL. Later users requesting the same route without the malicious header receive the cached 3xx response lacking a valid `Location` header, so their browsers cannot follow the redirect and the path appears broken until the cache object expires, is invalidated, or the application is patched and cache entries are purged.

How to fix it

Upgrade Next.js to a fixed release: 15.5.16 or later for the 15.x line, or 16.2.5 or later for the 16.x line. Applications running 12.2.0 or newer but older than those fixed versions should be treated as affected if they use middleware/proxy redirects. After upgrading, purge CDN and reverse-proxy caches for affected redirect paths to remove any previously cached malformed 3xx responses. As a defense-in-depth mitigation, configure CDNs and reverse proxies not to cache 3xx responses from middleware-controlled routes unless explicitly intended, or ensure cache keys vary on request headers that affect Next.js response behavior, including `x-nextjs-data`. Edge/WAF rules may also block or strip externally supplied `x-nextjs-data` headers from normal browser traffic unless the application has a known legitimate need for that header at the edge.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.16 or later, 16.2.5 or later, or otherwise outside the affected range. Test representative middleware redirect routes by requesting them both with and without the `x-nextjs-data` header and verify that normal browser requests receive a valid 3xx response containing a `Location` header. Confirm that responses influenced by `x-nextjs-data` are not cached and replayed to requests that do not contain the header. Inspect CDN/reverse-proxy configuration to verify 3xx caching behavior and cache-key variation. After remediation, purge edge caches and retest from an uncached client or with cache-bypass headers to verify malformed redirects are no longer served.

Typical attack path

1. Identify an internet-facing application built with an affected Next.js version.
2. Find routes where Next.js middleware/proxy returns redirects, such as authentication, locale, trailing-slash, or canonicalization redirects.
3. Send a crafted request to a redirecting route with the `x-nextjs-data` header present.
4. Trigger vulnerable behavior where the response uses `x-nextjs-redirect` instead of the browser-standard `Location` header.
5. Rely on a CDN or reverse proxy caching the malformed 3xx response without varying on `x-nextjs-data`.
6. Cause subsequent normal visitors to receive the poisoned cached redirect response and fail to navigate correctly.
7. Maintain disruption until cache expiration, manual purge, or deployment of a fixed Next.js version.

How to detect it

Review CDN, reverse-proxy, WAF, load balancer, and application access logs for requests containing the `x-nextjs-data` header to routes that return redirects. Pay particular attention to 3xx responses that include `x-nextjs-redirect` but lack a `Location` header, because that pattern indicates the vulnerable redirect transformation occurred. In CDN logs, look for a single unusual request with `x-nextjs-data` followed by cache hits for the same URL serving 3xx responses to clients that did not send the header. Investigate spikes in failed navigation, increased 3xx responses without `Location`, synthetic monitoring failures on redirect paths, or user reports that login/locale/canonical redirects stopped working. For forensic review, correlate the first observed malformed cached response with the requesting IP, user agent, URL path, CDN cache status, and cache object age. Because exploitation does not require malware or persistence, evidence is likely limited to HTTP logs, edge cache metadata, and application response headers rather than host artifacts.

• x-nextjs-data
• x-nextjs-redirect
• HTTP 3xx response with x-nextjs-redirect and no Location header
• request header: x-nextjs-data
• response header: x-nextjs-redirect
• cache hit 3xx response missing Location
• CF-Cache-Status: HIT
• X-Cache: HIT
• Age:

What your security team should do

• Inventory public Next.js applications and identify deployments running versions from 12.2.0 through versions before 15.5.16 and 16.2.5.
• Prioritize patching internet-facing applications that use middleware/proxy redirects and sit behind CDNs or reverse proxies that cache 3xx responses.
• Upgrade to Next.js 15.5.16 or later, or 16.2.5 or later, then purge CDN and reverse-proxy caches for redirecting routes.
• Review CDN and reverse-proxy cache rules to ensure malformed or header-dependent 3xx responses cannot be cached for all users.
• Add edge detection for external requests containing `x-nextjs-data`, especially when followed by 3xx responses containing `x-nextjs-redirect` and no `Location` header.
• Monitor availability metrics and synthetic checks for authentication, locale, canonicalization, and other redirect-heavy user journeys.
• If immediate patching is not possible, temporarily block or strip `x-nextjs-data` from untrusted external requests and disable caching of 3xx responses on middleware-controlled paths.