CVE-2026-64648

What it actually does

This is a server-side response cache confusion issue in Next.js affecting versions 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10. When application code performs a server-side fetch using a Request object and passes a different init object to fetch, a request with a body may receive a cached response body generated for another request to the same URL but with a different body. The outbound request itself is still made, but the response body returned to application code can be incorrectly reused. If the cached response contains user-specific, tenant-specific, session-specific, or otherwise confidential data, that data may be disclosed to an unauthorized requester. The issue is fixed in Next.js 15.5.21 and 16.2.11.

Why it matters to the business

Applications using affected Next.js versions may unintentionally show one user confidential data that belongs to another user, such as account details, profile data, order information, internal workflow results, or API-derived content. The risk is highest for applications that perform server-side POST or body-bearing fetch calls to sensitive backend endpoints and then render the response to users. Although EPSS is currently low and there is no CISA KEV listing or known exploit maturity in the supplied data, the flaw is remotely reachable through normal web application traffic when vulnerable code paths exist, so public-facing applications should be prioritized for upgrade.

How an attack unfolds

An attacker first identifies a user-facing route or workflow in a Next.js application that triggers a server-side fetch with a request body. The vulnerable application code constructs a Request object and then calls fetch with a different init object, creating the unsafe pattern where cache handling can associate responses by URL without correctly separating different request bodies. The attacker then sends crafted or repeated requests that cause the server to call the same backend URL with different body content. If a confidential response for another user's request to that same URL is present in the relevant cache path, the attacker's request can be served that cached response body instead of the response corresponding to the attacker's own request. The attacker does not need credentials for the victim's data if the application exposes such a vulnerable flow, but successful exploitation depends on the application using the unsafe fetch pattern and on sensitive responses being cacheable or reused in the affected manner.

How to fix it

Upgrade Next.js to a fixed version: use 15.5.21 or later on the 15.x line, or 16.2.11 or later on the 16.x line. For affected 12.x, 13.x, and 14.x deployments, upgrade to a supported fixed release line because the supplied fixed versions are 15.5.21 and 16.2.11. As a code-level mitigation, review server-side fetch usage and replace unsafe calls such as fetch(new Request(init), aDifferentInit) with a safe pattern where the Request and init are consistent, such as fetch(new Request(init), init), or otherwise ensure that request body, headers, authorization context, and cache behavior cannot be mismatched. For sensitive server-side requests, explicitly disable caching where appropriate by using no-store/no-cache semantics supported by the framework and application design. Avoid returning user-specific or confidential POST response bodies through cacheable paths unless the cache key fully includes user identity and request body semantics.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.21 or later, or 16.2.11 or later, using package manifests, lockfiles, build artifacts, and runtime dependency inventory. Search application code for server-side fetch calls where a Request object and a separate init object are both provided, especially where the init values differ or where request bodies are constructed dynamically. Test vulnerable workflows by issuing two requests to the same server-side endpoint that cause backend fetches to the same URL with different request bodies and user contexts; the response for each request should correspond only to that request's body and authenticated context. Review HTTP cache-control behavior for sensitive POST or body-bearing fetches and verify confidential response bodies are not reused across users or request bodies.

Typical attack path

1. Identify a public or authenticated application workflow built with an affected Next.js version.
2. Find a route that triggers server-side fetch calls with a request body, commonly POST-like backend API calls.
3. Send requests that cause the server to fetch the same backend URL with different request bodies.
4. Rely on or induce response-cache reuse where a response body from one request body is returned for a different request body.
5. Receive and inspect a response containing data associated with another request or user.

How to detect it

There is no reliable universal network signature for exploitation because the issue is application-logic dependent and the leaked response is produced by normal application traffic. To investigate possible prior exploitation, correlate web access logs, application request logs, server-side fetch/backend API logs, and CDN or reverse-proxy logs. Look for repeated requests to the same application route or backend URL with different request bodies, parameters, or user/session identifiers that received identical or unexpectedly similar response bodies. Focus on body-bearing server-side requests, especially POST-like workflows returning confidential data. Compare timestamps where one user's sensitive request was followed closely by another user's request to the same URL and the second response size, status code, cache metadata, or response hash matches the first. Review application error reports, support tickets, and audit trails for reports of users seeing other users' data. If response logging or structured audit events exist, search for mismatches between authenticated user identity and identifiers present in the returned data. If cache headers or framework debug logs are available, look for cache hits on routes or fetches that should vary by request body or user context.

What your security team should do

• Prioritize upgrading public-facing Next.js applications to 15.5.21 or 16.2.11 or later, especially applications handling personal, financial, health, account, or administrative data.
• Inventory applications running Next.js 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, including transitive framework use in monorepos and container images.
• Ask engineering teams to review server-side fetch patterns for fetch(new Request(...), ...) where the second argument is not the same init used to construct the Request.
• Disable caching for sensitive body-bearing server-side fetches until code review and upgrade are complete.
• Add regression tests for user-specific POST workflows to ensure responses cannot be mixed between different request bodies or user sessions.
• Review recent access logs for unusual repeated requests to the same application route with different request bodies followed by unexpected successful data access or user reports of seeing another user's data.