CVE-2026-64648: 
Wolfi vulnerability analysis and mitigation

CVE-2026-64648 is a cache confusion vulnerability in Next.js (App Router) that allows server-side fetch responses to be served from cache to requests with different request bodies, potentially leaking confidential data. It affects Next.js versions 13.0.0 through 15.5.20 and 16.0.0 through 16.2.10 running on Node.js; applications using the Pages Router are not affected. The vulnerability was published on July 22, 2026, and patched in versions 15.5.21 and 16.2.11. It carries a CVSS v3.1 score of 5.4 (Medium) and a CVSS v4.0 score of 6.0 (Medium) (GitHub Advisory).

The root cause is improper cache key construction in Next.js's patched fetch implementation (packages/next/src/server/lib/patch-fetch.ts), classified as CWE-524 (Use of Cache Containing Sensitive Information). When a fetch call is made using the pattern fetch(new Request(init), aDifferentInit), the cache key is derived from the base Request object rather than the effective merged request — meaning the init override (including a different request body) is not reflected in the cache key. As a result, a subsequent request to the same URL with a different body may receive a cached response body intended for a prior, different request. The fix merges the Request and init objects into a single effective Request before cache key computation, ensuring the cache key accurately reflects the actual request being made (GitHub Advisory, Patch 15.x, Patch 16.x).

Successful exploitation can expose confidential data — such as authentication tokens, session data, or user-specific information — from cached POST response bodies to unauthorized or unrelated requests. The impact is primarily a confidentiality breach (rated High in CVSS v4.0 for the vulnerable system), with a low integrity impact and no availability impact. The vulnerability is scoped to the server-side fetch cache within Next.js App Router applications and does not enable remote code execution or lateral movement, but data leakage between logically separate user sessions could facilitate account takeover or privilege escalation depending on the application's use of the affected fetch calls (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of publication (GitHub Advisory). The EPSS score is approximately 0.527%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires passive user interaction (i.e., a legitimate user must first make a request that populates the cache), and specific attack requirements must be present, making automated exploitation less straightforward.

1. Identify a vulnerable target: Locate a Next.js App Router application running versions 13.0.0–15.5.20 or 16.0.0–16.2.10 that uses server-side fetch calls with the unsafe pattern fetch(new Request(init), aDifferentInit) — for example, an API route that makes authenticated POST requests to a backend service.
2. Trigger cache population: Cause a legitimate user (or the application itself) to make a server-side fetch POST request to a target URL with a specific body (e.g., containing user-specific credentials or sensitive data). This populates the fetch cache with the response body keyed only on the base Request URL.
3. Send a request with a different body: As an unauthenticated or different user, trigger a server-side fetch to the same URL but with a different init (e.g., different POST body). Because the cache key does not incorporate the init override, the server returns the previously cached response body.
4. Extract sensitive data: Read the leaked response body, which may contain authentication tokens, user data, or other confidential information from the prior request (GitHub Advisory).

• Logs: Unexpected or repeated server-side fetch responses returning data inconsistent with the request body (e.g., user A's data returned for user B's request); application logs showing cache hits for POST requests that should not be cached.
• Application Behavior: Users receiving response data belonging to other users or sessions; authentication tokens or session identifiers appearing in responses for requests that did not supply them.
• Network: Unusual patterns of identical URL POST requests with varying bodies originating from different clients in rapid succession, potentially indicating an attempt to trigger cache confusion.

Upgrade Next.js to version 15.5.21 (for the 15.x branch) or 16.2.11 (for the 16.x branch), which contain the fix for this vulnerability. No configuration-based workaround exists — the advisory explicitly states that upgrading is the only remediation. As a defensive coding practice, developers should use the safe fetch pattern fetch(new Request(init), init) rather than fetch(new Request(init), aDifferentInit) to avoid triggering the caching bug in unpatched versions. Applications using the Pages Router are not affected and do not require action (GitHub Advisory, v15.5.21 Release, v16.2.11 Release).

The vulnerability was part of a broader July 2026 Next.js security release that addressed nine security flaws, including high-severity SSRF and DoS issues, which attracted significant media coverage. Security outlets including CyberSecurityNews, GBHackers, and SecureBulletin covered the release, framing it as an emergency patch batch. Cloudflare and Netlify both published changelog entries noting the Next.js security vulnerabilities, indicating rapid response from hosting providers (Next.js Blog, Netlify Changelog, CyberSecurityNews).