EUVD-2026-49565
GHSA-68g3-v927-f742
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector (server-side endpoint); AC:H because exploitation requires the specific vulnerable fetch pattern in application code; PR:N as the attacker sends a normal request; confidentiality high, no integrity or availability impact.
Primary rating from Vendor (https://github.com/vercel/next.js).
CVSS VectorVendor: https://github.com/vercel/next.js
Lifecycle Timeline
4Blast Radius
ecosystem impact- 16 npm packages depend on next (15 direct, 1 indirect)
Ecosystem-wide dependent count for version 13.0.0.
DescriptionCVE.org
Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This only applies to fetch calls with a request that has a different init than the one passed to fetch. Safe: fetch(new Request(init), init) Unsafe: fetch(new Request(init), aDifferentInit)
Workarounds
No workaround exists besides upgrading. Applications using Pages Router are not vulnerable.
AnalysisAI
Cache confusion in Next.js App Router's server-side fetch patch leaks confidential POST response bodies across unrelated requests targeting the same URL. Applications on Next.js 13.0.0 through 15.5.20 or 16.0.0 through 16.2.10 that call fetch(new Request(init), aDifferentInit) server-side are at risk of cross-user data exposure - one user's POST response (potentially containing session tokens, PII, or financial data) may be returned to a different user's request. No public exploit has been identified at time of analysis, and Pages Router deployments are explicitly unaffected.
Technical ContextAI
Next.js patches the native global fetch function on the server side (packages/next/src/server/lib/patch-fetch.ts) to enable its caching and revalidation infrastructure. When fetch is invoked with a Request object as the first argument and a separate init object as the second argument, native fetch lets init override fields on the base Request. Next.js's patched fetch was constructing the cache key from the original Request without first merging the init overrides, meaning two calls to the same URL with different request bodies could hash to the same cache entry. The root cause is CWE-524 (Use of Cache Containing Sensitive Information): the cache key did not fully represent the effective outbound request. The fix (commits 062f667 and 73b9487) merges the init overrides into the Request object before cache lookup so the key reflects the actual body, headers, and method. Affected packages are pkg:npm/next versions >= 13.0.0 < 15.5.21 and >= 16.0.0 < 16.2.11.
RemediationAI
Upgrade Next.js to version 15.5.21 (for 13.x-15.x deployments) or 16.2.11 (for 16.x deployments). The vendor advisory at https://github.com/vercel/next.js/security/advisories/GHSA-68g3-v927-f742 and release notes at https://github.com/vercel/next.js/releases/tag/v15.5.21 and https://github.com/vercel/next.js/releases/tag/v16.2.11 confirm these as the patched versions. The vendor explicitly states no workaround exists besides upgrading. As a temporary code-level mitigation, developers can audit server-side fetch calls and replace any fetch(new Request(url, init), differentInit) pattern with fetch(new Request(url, init), init) (same init object) or fetch(url, mergedInit) to avoid the cache key mismatch - however this is a code change, not a configuration workaround, and upgrading remains the definitive fix.
Same technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today