CVE-2026-64648: Vercel Next.js Information Disclosure Flaw

CVE-2026-64648 Overview

CVE-2026-64648 is an information disclosure vulnerability in Next.js, the React framework maintained by Vercel for building full-stack web applications. The flaw affects the server-side fetch cache and causes a request to return a cached response body belonging to a different request that shared the same URL but had a different body. When a fetch(new Request(init), aDifferentInit) pattern is used, confidential data from a prior POST response can leak to unauthorized callers. The issue affects versions 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, and is fixed in 15.5.21 and 16.2.11. The weakness is categorized under [CWE-524: Use of Cache Containing Sensitive Information].

Critical Impact
Server-side fetch calls with request-body overrides can return cached response bodies from unrelated requests, exposing confidential POST data to unauthorized clients.

Affected Products

Vercel Next.js versions 12.0.0 through 15.5.20
Vercel Next.js versions 16.0.0 through 16.2.10
Next.js applications deployed on Node.js runtimes using server-side fetch caching

Discovery Timeline

2026-07-27 - CVE-2026-64648 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-64648

Vulnerability Analysis

Next.js wraps the native fetch API with a caching layer implemented in packages/next/src/server/lib/patch-fetch.ts. When developers invoke fetch(input, init) where input is a Request object and init provides overrides, the native fetch semantics allow init to override values on the base Request, including the body. The Next.js cache layer failed to reconcile this override when computing the cache key. As a result, two logically distinct requests, differing in body, could map to the same cache entry. A subsequent request could then receive a cached response body originally produced for a different caller. Because POST responses are frequently used to return user-specific data, this cache collision constitutes an information disclosure across trust boundaries.

Root Cause

The root cause is inconsistent request normalization between the cache key and the effective outbound request. The wrapper derived cacheability signals from input while allowing init to independently modify the actual network request. Without merging the two into a single effective Request, the cache key did not reflect the body used on the wire, breaking the invariant that cached entries correspond to a unique request identity.

Attack Vector

Exploitation requires an application to server-side fetch a URL using the unsafe fetch(new Request(init), aDifferentInit) pattern where init supplies or alters the body. An attacker who can issue crafted requests to the affected route may retrieve a previously cached response body meant for another user or session. The attack is network-reachable and requires no authentication, though it depends on application-specific fetch usage.

typescript

// Security patch in packages/next/src/server/lib/patch-fetch.ts
// Fix: key fetch(Request, init) by the effective request
           typeof input === 'object' &&
           typeof (input as Request).method === 'string'
 
+        // With `fetch(new Request(url), init)`, native fetch lets `init`
+        // override the base Request. Merge them into a single effective Request
+        // so cacheability, the cache key, and the upstream request all describe
+        // the same thing.
+        if (isRequestInput && init) {
+          // `next` (revalidate/tags) is Next-specific and dropped by
+          // `new Request`, so keep it on `init` and move the rest onto input.
+          const { next, ...overrides } = init
+          input = new Request(input as Request, overrides)
+          init = next ? { next } : undefined
+        }
+
         const getRequestMeta = (field: string) => {
           // If request input is present but init is not, retrieve from input first.
           const value = (init as any)?.[field]
// Source: https://github.com/vercel/next.js/commit/062f66700b52a5d6bba2c0605d55577ab7ad262c

The patch merges init overrides into a new effective Request before deriving the cache key, ensuring the key, cacheability check, and upstream request all describe the same operation. The next field, which carries Next.js-specific revalidate and tags metadata, is preserved separately because new Request would otherwise drop it.

Detection Methods for CVE-2026-64648

Indicators of Compromise

Unexpected response bodies returned to clients that do not match the request body they sent, particularly for POST calls made through server components or route handlers.
Application logs showing identical upstream cache keys for requests with divergent payload hashes.
User reports of seeing another account's data on pages that perform server-side POST fetches.

Detection Strategies

Audit source code for the pattern fetch(new Request(...), init) where the second init argument differs from the one used to construct the Request. This is the specific unsafe usage identified in GHSA-68g3-v927-f742.
Inventory installed Next.js versions across build pipelines and compare against the fixed releases v15.5.21 and v16.2.11.
Instrument the fetch cache layer in non-production environments to log computed cache keys alongside request body digests to surface collisions.

Monitoring Recommendations

Correlate application error rates and cross-user data exposure reports with deployments running vulnerable Next.js versions.
Monitor egress fetches from Next.js servers for anomalous cache-hit ratios on POST requests, which the framework should not typically cache.
Track dependency SBOM changes so that upgrades to patched Next.js versions are verified in production.

How to Mitigate CVE-2026-64648

Immediate Actions Required

Upgrade Next.js to 15.5.21 for the 15.x branch or 16.2.11 for the 16.x branch as documented in the Vercel security advisory.
Identify and refactor call sites that pass a differing init to fetch(new Request(init), init2); use fetch(new Request(init), init) or a single unified argument.
Invalidate or purge the Next.js data cache after upgrading to remove any poisoned entries produced under the vulnerable code path.

Patch Information

The fix is delivered in commits 062f667 for the 15.x branch and 73b9487 for the 16.x branch. Both patches modify packages/next/src/server/lib/patch-fetch.ts to construct an effective Request that reflects any init overrides before cache key derivation. Fixed releases are v15.5.21 and v16.2.11.

Workarounds

Avoid passing a distinct init argument alongside a preconstructed Request. Construct the Request with all final options and call fetch(request) with no second argument.
Disable Next.js data cache for routes that issue POST requests carrying sensitive bodies by setting cache: 'no-store' on the fetch call.
Route sensitive POST traffic through server actions or handlers that bypass the patched fetch wrapper until the upgrade is deployed.

bash

# Upgrade to a patched Next.js release
npm install next@15.5.21
# or for the 16.x branch
npm install next@16.2.11

# Verify the installed version
npx next --version