GHSA-wm8w-6qjm-cv43 CVE-2026-71316

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

High npm

Severity: 7.5 / 10; High · CVSS 3.1
Exploit chance (EPSS): 0.51%; Chance of exploitation in the next 30 days. Higher than 43.29% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-524 Use of Cache Containing Sensitive Information; CWE-862 Missing Authorization
Fix: 4.5.1; Upgrade nuxt to this version or later

Description

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 versions

npm

Package	Vulnerable	Fixed in
nuxt	`>= 4.4.0, < 4.5.1`	`4.5.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

nuxt npm → `4.5.1`

npm

npm install nuxt@4.5.1

yarn

yarn add nuxt@4.5.1

pnpm

pnpm add nuxt@4.5.1

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: None
Availability: None

Weakness

CWE-524: Use of Cache Containing Sensitive Information

The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

How to prevent it

Architecture and Design: Protect information stored in cache.
Architecture and Design: Do not store unnecessarily sensitive information in the cache.
Architecture and Design: Consider using encryption in the cache.

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Packages

github.com/nuxt/nuxt

Timeline

Aug 5, 2026 Published
Sep 8, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-9v7c-q64q-vv33 Nuxt: Dot segments in the request path bypass `server/middleware` path checks and server route rules on page routes	Medium	Also affects nuxt
GHSA-xfq5-w38q-pc2x Nuxt server islands render `useHeadSafe` input without sanitisation	Medium	Also affects nuxt
GHSA-vjh5-4x84-xrqp Nuxt: Server-side route rules (`redirect`, `headers`, `proxy`, `ssr`) are skipped for case-variant paths when routing is case-insensitive	Medium	Also affects nuxt
GHSA-6gq8-jgmh-3ffp Nuxt: Route rules are matched against the raw request path, so a percent-encoded segment can bypass `appMiddleware` on dynamic and catch-all routes	Medium	Also affects nuxt
GHSA-jjm6-p2m9-9w4x Nuxt: Incomplete fix for GHSA-934w-87qh-qr26: a `javascript:` URL prefixed with an ASCII control character executes from `<NuxtLink>` when `pages` is disabled	Low	Also affects nuxt
GHSA-7c4v-fwgw-9rf7 Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint	Medium	Also affects nuxt
GHSA-9pgf-384g-p7mv Nuxt: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation	High	Also affects nuxt
GHSA-9473-5f9j-94wq Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props	High	Also affects nuxt

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor