High

Nuxt runtime payload cache discloses another user's SSR data across users and to unauthenticated clients

  • Disclosed: 05.08.2026
  • Updated: 11.10.2026 10:22

Impact

When a page is covered by routeRules cache / swr / isr, Nuxt enables runtime payload extraction and serves /<page>/_payload.json. On affected versions the renderer stored the SSR payload in the shared cache:nuxt:payload storage under a path-only key (no cookie, authorization, or cache.varies dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again.

As a result, once any authenticated user warms a protected, cached page, a subsequent GET /<page>/_payload.json from an unauthenticated client or a different authenticated user receives the first user's payload: the full SSR data for that route, including anything loaded via useFetch / useAsyncData (for example /api/me: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. cache.varies does not mitigate it, because the payload cache ignores varies.

Introduced when runtime payload extraction landed for cached routes (#34410); the regression is specific to the 4.x line, where the runtime cache:nuxt:payload storage was added and the import.meta.prerender gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected.

Patches

Fixed in nuxt@4.5.1. Runtime payload-cache reads and writes are again confined to prerendering (import.meta.prerender); at runtime, /<page>/_payload.json follows the normal render path so route middleware, routeRules.appMiddleware, and page guards run for the current request. main / v5 and the 3.x line already had this property, so 3.x is not affected.

Workarounds

  • Set experimental.payloadExtraction: false (reporter-validated): the standalone /_payload.json endpoint returns 404 and the page still serves a 200 with an inline payload.
  • Do not apply cache / swr / isr to authenticated pages that render user-specific SSR data.
  • As defense-in-depth, require authentication for /**/_payload.json at a proxy / CDN.
  • After upgrading, purge any CDN / platform cache that may already hold protected payloads.

Affected software

Click a technology to see all vulnerabilities affecting it.

PlatformPackageVulnerable versionsFixed in
npm package nuxt >= 4.4.0, < 4.5.1 4.5.1

References

CVSS score 7.5/10
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness (CWE)
CWE-524, CWE-862
Platform
npm
Package
nuxt
Disclosed
05.08.2026
Updated
11.10.2026 10:22

Sources and licenses

OSV / GitHub Advisory Database - GHSA-wm8w-6qjm-cv43 - CC BY 4.0

Vulnerability history: nuxt

All published vulnerabilities of this package (npm package), newest first. Shows whether this is a one-off slip or a package that needs watching.

All (21) in the archive
Total entries
21
First → latest
06.2023 08.2026
Without a fix
0
Exploited in attacks
0

Severity breakdown

  • Critical 2
  • High 7
  • Medium 8
  • Low 4

Disclosures per year

  1. 2023: 1
  2. 2024: 2
  3. 2025: 2
  4. 2026: 16
Severity:
  1. High · 7.5 CVE-2026-71321 >= 4.0.0, < 4.5.1, >= 3.1.0, < 3.21.10 4.5.1, 3.21.10
  2. High · 8.1 CVE-2026-71320 >= 4.0.0, < 4.5.1, >= 3.4.0, < 3.21.10 4.5.1, 3.21.10
  3. Nuxt runtime payload cache discloses another user's SSR data across users and to unauthenticated clients this entry
    High · 7.5 CVE-2026-71316 >= 4.4.0, < 4.5.1 4.5.1
  4. High · 8.2 CVE-2026-71315 >= 4.4.7, < 4.5.1, >= 3.21.7, < 3.21.10 4.5.1, 3.21.10
  5. High · 7.5 CVE-2026-71314 >= 4.0.0, < 4.5.1, >= 3.1.0, < 3.21.10 4.5.1, 3.21.10
  6. High CVE-2026-53721 >= 4.0.0, < 4.4.7, >= 3.11.0, < 3.21.7 4.4.7, 3.21.7
  7. High · 7.5 CVE-2025-27415 >= 3.0.0, < 3.16.0 3.16.0
  8. Critical · 8.8 CVE-2024-34344 >= 3.4.0, < 3.12.4 3.12.4
  9. Critical · 8.1 CVE-2023-3224 >= 3.4.0, < 3.4.3 3.4.3

Know which vulnerabilities affect your application

With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.

Connect your application
DockRay newsletter

Application security in your inbox

Important vulnerabilities, actionable guidance and practical advice for your applications. Choose your technologies and follow what matters to your project.

  • A daily digest of new vulnerabilities, critical ones included.
  • Notifications about important updates.
  • Practical advice on application security and monitoring.

Leave empty to receive updates for every technology.

Free to subscribe. Unsubscribe with one click in any email.