Skip to main content
VulnerabilityPublished

CVE-2026-64648: vercel next.js · Use of Cache Containing Sensitive Information

Affects vercel next.jsSource CVE Database V5

0

Not known to be exploited · CVSS 6.0 Medium : upgrade to 16.2.11 or 15.5.21 when convenient.

Data as of 26 Oct 2026, 12:55 UTC

CVSS 4.0 base score
6.0Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 26% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-07-28.

Patch
Available – fixed in 16.2.11, 15.5.21
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade vercel next.js to 16.2.11 or 15.5.21.

Affected software

ProductAffectedFixed in
vercelnext.jsAffected
  • >=16.0.0 <16.2.11
Fixed in
  • 16.2.11
vercelnext.jsAffected
  • >=13.0.0 <15.5.21
Fixed in
  • 15.5.21

Description

Next.js is a React framework for building full-stack web applications. In versions 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, 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. A safe request would be: fetch(new Request(init), init). An unsafe request would be: fetch(new Request(init), aDifferentInit). This issue has been fixed in versions 15.5.21 and 16.2.11.

References

Community reviews

Loading reviews…