Next.js CVE-2026-44572
LOWSeverity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Lifecycle Timeline
3Blast Radius
ecosystem impact- 19 npm packages depend on next (17 direct, 2 indirect)
Ecosystem-wide dependent count for version 12.2.0.
DescriptionGitHub Advisory
Impact
Next.js uses the x-nextjs-data request header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.
When that happened, the middleware/proxy could treat the request as a data request and replace the standard Location redirect header with the internal x-nextjs-redirect header. Browsers do not follow x-nextjs-redirect, so the response became an unusable redirect for normal clients.
If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a Location header, causing a denial of service for that redirect path until the cache entry expired or was purged.
Affected scenarios
This affects applications that:
- use middleware or proxy redirects
- are deployed behind a caching CDN or reverse proxy
- allow 3xx responses on those paths to be cached without differentiating internal data requests from normal requests
Fix
The fix stops trusting x-nextjs-data by itself for middleware redirect handling. A request is now treated as an internal data request only when it is validated as such by internal routing state, preserving legitimate data-request redirect behavior while preventing external header injection from changing normal redirect responses.
Workarounds
Before upgrading, users can reduce risk by:
- configuring the CDN or reverse proxy to vary its cache key on
x-nextjs-datafor affected responses
AnalysisAI
Cache poisoning in Next.js middleware redirect handling allows attackers to inject a malicious x-nextjs-data request header, causing middleware to replace the standard Location header with an internal x-nextjs-redirect header that browsers ignore. When deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request can poison the cached redirect, resulting in denial of service for that redirect path for all subsequent visitors until cache expiration. Affects Next.js versions 12.2.0-15.5.15 and 16.0.0-16.2.4; vendor-released patches available in 15.5.16 and 16.2.5.
Technical ContextAI
Next.js uses the x-nextjs-data request header internally to signal data requests from the client-side router, allowing the server to return optimized responses without full page HTML. The vulnerability stems from CWE-349 (Acceptance of Extraneous Untrusted Data Element) - the middleware logic trusted the x-nextjs-data header itself without validating it against internal routing state. When an external attacker spoofs this header on a normal request to a path handled by middleware that returns a 3xx redirect, the server incorrectly treats it as an internal data request and substitutes the standard HTTP Location header with the proprietary x-nextjs-redirect header. Since browsers do not follow x-nextjs-redirect, the response becomes unusable. If a CDN or reverse proxy caches 3xx responses with a cache key that does not vary on x-nextjs-data (a common default behavior), a single attacker request populates the cache with a broken redirect, poisoning it for all downstream users. The fix validates x-nextjs-data only when corroborated by internal routing state, preventing external header injection from altering redirect behavior.
RemediationAI
Upgrade Next.js to version 15.5.16 (for the 15.x branch) or 16.2.5 (for the 16.x branch) or later. These versions validate x-nextjs-data against internal routing state, eliminating the header injection vector. Before upgrading, configure your CDN or reverse proxy to vary the cache key on the x-nextjs-data header for all 3xx responses, preventing cache poisoning even if external clients send the header. This workaround has minimal performance impact (adds one header to the cache key) and does not alter application behavior. Alternatively, disable caching of 3xx responses on the affected middleware redirect paths if feasible, though this may increase origin load. Monitor CDN cache-hit ratios after applying the cache-key variance to ensure the workaround does not degrade performance unacceptably; for most deployments, the overhead is negligible.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-3g8h-86w9-wvmq