CVE-2026-71316: Information Disclosure and Authorization Bypass in Nuxt Runtime Payload Caching

Nuxt is an open-source web framework based on Vue.js that facilitates server-side rendering (SSR), static site generation, and hybrid caching strategies like Stale-While-Revalidate (SWR) and Incremental Static Regeneration (ISR). To optimize client-side hydration during subsequent page navigations, Nuxt extracts the serialized server-side rendering state (containing state hydrated by server-bound composables like useFetch or useAsyncData) and exposes it through static-like payload endpoints at /<page>/_payload.json.

Historically, writing to and reading from this payload cache was strictly confined to static site generation and prerendering environments where the code is executed in a controlled, non-dynamic setting. However, starting in Nuxt version 4.4.0, a refactoring of the internal runtime storage engines removed these guardrails. This change allowed runtime payload caching to be activated globally across the server environment within a shared memory or disk store named cache:nuxt:payload.

This global activation introduced a severe security flaw because the shared storage keyspace does not isolate cached payloads based on session identifiers, authorization headers, or cookies. Consequently, any dynamic, user-specific data server-rendered for an authenticated client is cached under a path-based key. When subsequent requests are made to the _payload.json endpoint for that path, the server returns the cached JSON without evaluating access control logic, leading to complete information disclosure of other users' sessions.

The root cause of CVE-2026-71316 lies in a combination of unsegmented global cache keying (CWE-524) and premature request interception that bypasses access control mechanisms (CWE-862). In Nuxt's server-side rendering pipeline, when a user accesses a route configured with SWR, ISR, or general caching rules, the system attempts to determine if a pre-rendered payload already exists. This lookup resolves inside the Nitro server runtime handler before application-level middleware, page guards, or session checks are executed.

To construct the cache identifier, Nuxt employs a helper function named getPayloadCacheKey. This function generates keys using solely the request URL path (for example, /profile). Because variables like authorization headers, CSRF tokens, session cookies, and IP addresses are completely absent from the key derivation function, all users—regardless of their privilege levels or authentication states—are mapped to the exact same cache keyspace.

This design flaw creates a dangerous race and storage condition in multi-user environments. When an authenticated user triggers a page load, their unique, private user data is fetched on the backend and serialized into the SSR state. This private state is then saved to the global, shared payloadCache mapping. Subsequent requests from other, potentially unauthenticated users for the corresponding _payload.json file retrieve this stored entry directly from the global cache, entirely avoiding the page-level security controls that would normally prevent unauthorized access.

To fully understand the implementation bug, we must review the vulnerability path in packages/nitro-server/src/runtime/handlers/renderer.ts. In the vulnerable versions (Nuxt 4.4.0 up to 4.5.0), the handler processed requests for dynamic payloads by resolving them against the shared payload cache unconditionally at runtime:

// VULNERABLE IMPLEMENTATION
const cacheKey = getPayloadCacheKey(ssrContext.url)
if (payloadCache && await payloadCache.hasItem(cacheKey)) {
  // Returns the cached response immediately, bypassing route middleware entirely
  return payloadCache.getItem(cacheKey) as Promise<Partial<RenderResponse>>
}

The corresponding patch in commit ac9b41a36b62296a117862254ee7d2b21a2a5203 enforces that payload cache lookups and writes are restricted to static generation/prerendering by validating import.meta.prerender:

// PATCHED IMPLEMENTATION IN v4.5.1
const cacheKey = getPayloadCacheKey(ssrContext.url)
// Check that the request occurs strictly during static site generation / prerendering
if (import.meta.prerender && payloadCache && await payloadCache.hasItem(cacheKey)) {
  return payloadCache.getItem(cacheKey) as Promise<Partial<RenderResponse>>
}

Additionally, the patch disabled the instantiation of the runtime payload cache storage entirely within packages/nitro-server/src/runtime/utils/cache.ts. By setting the export to null unless the framework is executing inside a prerender pipeline, any runtime attempts to reference payloadCache evaluate as false, effectively preventing runtime storage contamination:

// PATCHED cache.ts - Runtime payload cache is disabled
export const payloadCache: Storage | null = import.meta.prerender
  ? useStorage('internal:nuxt:prerender:payload')
  : null

This structural fix is highly complete and robust. By decoupling runtime request processing from the global payload storage entirely and forcing the runtime to execute the full SSR render pipeline, Nuxt ensures that every runtime dynamic request evaluates application-level middlewares, route rules, and authentication guards.

Exploitation of this vulnerability is straightforward and requires no advanced privileges or specialized tooling. The primary requirement is that the targeted route must employ Stale-While-Revalidate (SWR) or Incremental Static Regeneration (ISR) rules, and must handle user-specific sensitive data via SSR composables. The attacker first identifies such endpoints, typically dashboard subpaths or profile routes, which exhibit static-like suffix targets.

Once a route like /account/settings is target-mapped, the exploit relies on standard client navigation. When a legitimate, authorized user logs in and navigates to /account/settings, the server retrieves their profile details, generates the server-side state, and outputs the page content. Concurrently, the server saves the serialized data into the /account/settings/_payload.json cache index.

An unauthenticated attacker can then issue a direct HTTP GET request targeting the _payload.json endpoint of that route. Because the server evaluates the request against the shared cache keyspace first, it matches the active cache entry and returns the full JSON representation of the authorized user's state. The response includes sensitive variables like API tokens, email addresses, and database records, bypassing all front-end and back-end route guards.

The impact of CVE-2026-71316 is classified as High, with a CVSS v3.1 base score of 7.5. The primary security impact is the unauthorized disclosure of high-confidentiality user records, session identifiers, and proprietary data. In modern single-page applications built on Nuxt, server-side data extraction often contains sensitive metadata, internal API keys, database identifiers, and personally identifiable information (PII) required to hydrate the client-side state.

Because the information disclosure occurs at the server framework layer, standard browser-level protections such as the Same-Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS) provide no defense against direct server querying. Any remote, unauthenticated attacker on the internet can scan and query these endpoints at scale, resulting in widespread account harvesting and session hijacking if session tokens are exposed within the SSR payload state.

Fortunately, there is currently no evidence of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, due to the trivial nature of the exploit sequence and the ubiquity of Nuxt in modern web architectures, the risk of weaponization remains high for unpatched applications that rely on hybrid rendering and caching strategies.

The recommended path to remediation is upgrading the Nuxt installation to version 4.5.1 or higher. This release contains the complete set of patches that restrict runtime payload extraction to static build contexts and disable runtime global caching drivers. Developers should execute a clean dependency resolution (npm update nuxt or yarn upgrade nuxt) and verify their locks to confirm that the resolved version satisfies the safe range.

In scenarios where immediate upgrades are blocked by architectural constraints, developers can temporarily mitigate the risk by globally disabling runtime payload extraction. This is accomplished by setting the payloadExtraction flag to false in the nuxt.config.ts configuration file. This setting stops the framework from writing dynamic JSON payloads and forces client-side hydrations to fallback to standard server-rendered HTML blocks.

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    payloadExtraction: false
  }
})

Additionally, operations teams should inspect downstream caching systems, such as Content Delivery Networks (CDNs), web application firewalls (WAFs), or reverse proxies. Rules must be defined to strip or ignore caching headers for any URL ending in _payload.json if those routes handle authentication or user-specific records. Finally, immediate cache purges should be triggered across all CDN edges to eliminate stale, poisoned payloads that may have been cached prior to applying the patch.