GHSA-3g8h-86w9-wvmq

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