NEXT · CVE-2026-119790 · Package
FIX → 16.4.5
Next.js apps that call a 'use cache' function both directly and through unstable_cache() can, during a race right after process start, store data produced for one root param value and return it to requests for other root param values. An attacker can read cached data scoped to another user's route parameter, such as a locale.
first public Nov 3, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications on Next.js 16.3.0 through 16.4.4 that use 'use cache' with root params and also call the same cached function through unstable_cache(). Exposure is limited to the window while a function's first fill after a cold start is in flight. Apps without that nesting are not affected.
Not affected if default-config, no-root-params, no-unstable-cache
Who cares next.js, self-hosted, vercel
'use cache' functions that read a root param and are also called inside unstable_cache() in the app code.npm ls next; affected versions are >= 16.3.0 and <= 16.4.4.Upgrade to 16.4.5
Next.js applications with 'use cache' can disclose cached data across root params when the same 'use cache' function is called both directly during rendering and through unstable_cache(), and that function reads a root param. Root params are route parameters of the root layout, and applications commonly use them to scope data, for example per locale.
During a cold process start, a cross-request deduplication race allowed an unstable_cache() call to join the in-flight fill of a concurrent direct call and receive its result, bypassing the root param check that would normally reject it. unstable_cache() then stored that result under a cache key without root params, so subsequent requests for other root param values received the same entry until it is revalidated or evicted. Cached data produced for one root param value is returned to requests for other values.
Exploitation requires the unstable_cache() request to arrive while the function's first fill after a process start is still in flight. Outside this race, the nesting already throws an error: 'use cache' inside unstable_cache() is unsupported, and avoiding it is a complete workaround.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
next to 16.4.5.unstable_cache().