EUVD-2026-49404
GHSA-4633-3j49-mh5q
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/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, no privileges required, but AC:H because exploitation depends on a pre-existing colliding cache entry from a prior request.
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 is only an issue when receiving request bodies with a content type charset other than UTF-8. For example, the UTF-16 byte sequences for 삃삃 and 섄섄 in the request body would share the same cache.
Workarounds
If you cannot upgrade, consider only making fetch requests with UTF-8 bodies (default in Next.js). Applications using Pages Router are not vulnerable.
AnalysisAI
Cache key collision in Next.js server-side fetch exposes confidential POST response bodies to unintended callers when request bodies contain non-UTF-8 byte sequences. Specifically, the incremental cache's key-generation routine decoded raw body bytes through a TextDecoder, causing distinct byte sequences - such as UTF-16 encodings - to collapse to the same replacement-character string (U+FFFD) and therefore the same cache key. A request whose body coincidentally produces a colliding cache key will receive a cached response intended for a different body, leaking whatever confidential data the upstream service returned. No public exploit has been identified at time of analysis; vendor-released patches are available in v15.5.21 and v16.2.11.
Technical ContextAI
Next.js (npm/next) implements a server-side incremental fetch cache inside packages/next/src/server/lib/incremental-cache/index.ts. When an App Router page or Server Component invokes fetch() with a request body, Next.js builds a cache key by serialising the body alongside a version prefix and optional fetch-cache-key-prefix. The vulnerable code path used the Web API TextDecoder to decode raw body bytes into a UTF-8 string for inclusion in the cache key. CWE-116 (Improper Encoding or Escaping of Output) captures the root cause: bytes that are not valid UTF-8 - including multi-byte encodings such as UTF-16 - are replaced with the Unicode replacement character U+FFFD, causing two lexically distinct byte sequences to produce identical decoded strings and therefore an identical cache key. The fix, applied in PR #96008 and commit 025bf4a5, replaces TextDecoder with a hand-written toHex() loop that losslessly encodes every byte as its two-digit hex representation, guaranteeing uniqueness. The cache-entry version prefix was also bumped from 'v3' to 'v4' to bust previously stored colliding entries. Affected packages are pkg:npm/next versions >=13.0.0 and >=16.0.0 prior to the respective fixed releases.
RemediationAI
The primary fix is to upgrade Next.js to v15.5.21 (for the 13.x-15.x line) or v16.2.11 (for the 16.x line). Both versions are available on npm and the patches are confirmed by the upstream commit 025bf4a5f7b47fb7758c4ebf1c931a61c451c082 and PR #96008 at https://github.com/vercel/next.js/pull/96008. After upgrading, the cache-entry version prefix bumps from 'v3' to 'v4', which automatically invalidates any previously stored colliding entries - no manual cache flush is required but is advisable in production to be safe. If immediate upgrade is not feasible, the vendor-documented workaround is to ensure all server-side fetch calls use only UTF-8 encoded request bodies, which is already the default in Next.js when bodies are plain strings or standard FormData. Applications that explicitly pass ArrayBuffer, Uint8Array, or Blob bodies with non-UTF-8 charset content should audit those call sites and transcode bodies to UTF-8 before issuing the fetch. This workaround carries a risk that non-UTF-8 semantics of the upstream API may be altered, so functional testing is advised.
Same weakness CWE-116 – Improper Encoding or Escaping of Output
View allSame technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today