GHSA-3g8h-86w9-wvmq Next.js's Middleware / Proxy redirects can be cache-poisoned

• npm next: >= 12.2.0, < 15.5.16 → fixed in 15.5.16 • npm next: >= 16.0.0, < 16.2.5 → fixed in 16.2.5

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