Summary
A Nuxt caching flaw can return server-rendered payload data from cached /<page>/_payload.json responses before route middleware and page guards run. When cached payloads contain user-specific SSR data, an attacker may access information belonging to another user without satisfying the intended authorization checks.
Affected context
The issue occurs in Nuxt applications using runtime caching for page payloads and SSR-generated data. It is relevant when payload responses can contain user-specific or authorization-dependent content, while cache delivery occurs before route middleware and page guards are enforced. The affected release range is Nuxt 4.4.0 through 4.5.1, with the issue addressed in 4.5.1.
Exploit preconditions
- Attack surface: HTTP access to a Nuxt-rendered page or its associated
_payload.jsonendpoint - Required access: The ability to request a cached page payload; valid application authentication may not be required for the affected response path
- Trigger point: Retrieval of a runtime cache entry for
/<page>/_payload.json - Why exploitation is possible: Cached SSR data may be served before route middleware and page guards determine whether the requester is authorized to receive it
Why this happens
The underlying flaw is an authorization-ordering and cache-handling problem. Runtime cache entries for SSR payloads can be returned without enforcing the import.meta.prerender condition that separates safe prerendered content from request-specific data. This allows cache delivery to occur before access-control logic, mapping primarily to CWE-524: Use of Cache Containing Sensitive Information and also to CWE-862: Missing Authorization.
Potential impact
- Sensitive SSR data may be disclosed to an unauthorized user
- User-specific page content could be exposed across sessions
- Application confidentiality may be reduced
- Cached authorization-dependent responses could bypass intended access controls
General mitigation guidance
Mitigation generally focuses on separating public, deterministic prerendered content from user-specific SSR responses.
Common defensive patterns include:
- Preventing caching of responses containing authentication- or user-dependent data
- Enforcing authorization and route guards before serving cache entries
- Using cache keys that incorporate all security-relevant request context where caching is necessary
- Applying explicit cache-control policies to sensitive payload endpoints
- Restricting runtime cache access and minimizing the data included in SSR payloads
- Using secure-by-default framework configuration that does not treat request-specific data as publicly reusable
How teams detect issues like this
Organizations can assess this class of issue through:
- Static analysis and configuration review for cached SSR payload routes
- Code review checks confirming that authorization runs before cache retrieval
- Tests that request the same page under different user identities and compare returned payloads
- Monitoring for cache responses containing identifiers, permissions, tokens, or other user-specific fields
- Policy enforcement requiring explicit cacheability decisions for authenticated or authorization-dependent responses
- Automated security review tools that flag sensitive data in cacheable responses and missing authorization checks
