Next.js's Middleware / Proxy redirects can be cache-poisoned

### 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

Quoted source text, attributed separately from HOL analysis.