Next.js EUVD-2026-90872

Exploitation requires the opt-in Cache Components feature enabled (cacheComponents: true) on Next.js 16.3.0 through 16.3.7, AND an application structure where a 'use cache' function calls another 'use cache' function that reads a value from next/root-params, AND the app differentiates content by root param values (e.g. multi-tenant, multi-locale, or multi-region routing). The leak is not attacker-controllable: which root-param value's content gets served depends solely on which invocation populated the shared cache entry first, so there is no reliable way to target a specific victim's data. Limiting factors: the vulnerable feature is non-default/opt-in, apps without nested 'use cache' calls reading root params are unaffected, and the flaw is fully remediated by upgrading to 16.3.8. Shared cache headers can widen blast radius by letting downstream CDN/proxy caches redistribute the mismatched content.

This is a genuine but modest-severity information-disclosure/cache-correctness flaw, not an emergency. The vendor CVSS 4.0 score of 6.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L only) is internally consistent with the description: network-reachable, no auth, but an Attack Requirement (AT:P) reflects that exploitation depends on race-like timing - specifically which invocation writes the shared cache entry first - rather than any attacker-steered input. Crucially, the description states twice that the leaked values CANNOT be attacker controlled and that which value is served 'depends only on which invocation wrote the entry first,' so this behaves as an accidental cross-root-param content-substitution bug rather than a targeted exfiltration primitive; confidentiality impact is correctly capped at VC:L (VI/VA:N). There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so there is no public exploit identified at time of analysis. The main amplifier is deployment reach: Next.js is extremely widely deployed, but this specific defect only manifests when the opt-in Cache Components feature (cacheComponents: true) is enabled AND an app uses nested 'use cache' functions where an inner call reads a root param - a narrow configuration that sharply limits the realistically affected population. Net: real priority only for teams running Cache Components in multi-root-param apps; for everyone else it is a high-CVSS-product / low-real-risk situation. No key signals conflict, though the 'passive, non-attacker-controlled' nature means the practical risk is content-correctness/privacy leakage rather than classic exploitation.

A Next.js site (16.3.0-16.3.7) runs with cacheComponents: true and serves per-tenant or per-locale pages keyed on a root param, where an outer 'use cache' function calls an inner 'use cache' function that reads that root param. The inner call is served from an existing entry, so the outer function's cache key omits the root param; the first request to populate it writes content for one root-param value, and every subsequent request for other values is served that same cached content, with shared cache headers potentially fanning it out through downstream CDNs. No public exploit code exists, and the outcome is non-deterministic cross-value content substitution rather than attacker-chosen data retrieval.