Skip to main content

Next.js CVE-2026-44572

LOW
Acceptance of Extraneous Untrusted Data With Trusted Data (CWE-349)
2026-05-11 https://github.com/vercel/next.js GHSA-3g8h-86w9-wvmq
3.7
CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY
3.7 LOW
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
Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

Lifecycle Timeline

3
Source Code Evidence Fetched
May 11, 2026 - 16:31 vuln.today
Analysis Generated
May 11, 2026 - 16:31 vuln.today
CVE Published
May 11, 2026 - 16:12 nvd
LOW 3.7

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 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-data for 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.

Share

CVE-2026-44572 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy