By supplying an extremely large integer as the iterated prop, an attacker causes the Nuxt server to allocate memory proportional to the iteration count, leading to an out-of-memory (OOM) crash of the worker process. The vulnerability impacts both direct 'v-for' directives on props and slot-based 'v-for' expansion via the 'vforToArray' utility. Successful exploitation requires only a small (approx. 130-byte) HTTP request. Organizations using Nuxt for SSR should update to the patched versions immediately or implement input clamping for props passed to 'v-for' within server components.

Attack Chain

1. Attacker identifies a Nuxt application using server-side rendered islands or components that perform 'v-for' iterations on user-provided props.
2. Attacker inspects public-facing island URL hash generation to understand the request digest format.
3. Attacker constructs a malicious request containing a crafted prop value, specifically a high-integer value intended for a 'v-for' loop.
4. Attacker submits the request to the target endpoint, typically targeting the /__nuxt_island/ path.
5. The Nuxt SSR engine processes the request and maps the attacker-supplied integer to the 'v-for' iteration logic.
6. The rendering engine expands the loop during SSR, leading to rapid, unbounded memory allocation within the worker process.
7. The server process exhausts system memory and crashes, resulting in a denial-of-service for the application.

Impact

Successful exploitation results in an immediate denial-of-service condition for the targeted application instance. A single small request (approx. 130 bytes) is sufficient to crash a worker process when provided with an iteration count in the tens of millions. This allows for trivial, unauthenticated resource exhaustion and service unavailability across affected infrastructure.

Recommendation

• Update to Nuxt 4.5.1 or 3.21.10 to incorporate the 'MAX_VFOR_LENGTH' clamping logic, which prevents unbounded iteration expansion.
• Audit application code for components utilizing 'v-for' on props passed from server-side inputs.
• Deploy manual input validation or clamping in server components using 'Math.min(count, 1000)' to provide defense-in-depth until patching is complete.
• Monitor webserver logs for unusual spikes in 500-series status codes targeting the /__nuxt_island/ endpoint, which may indicate crash attempts.

Attack Chain

1. The target application is configured with routeRules using cache, swr, or isr on protected pages that display user-specific data.
2. An authenticated user accesses a protected, cached route, triggering the server to generate and store the SSR payload in the cache:nuxt:payload store.
3. The cached payload is stored using only the URL path as the key, lacking any session or authorization awareness.
4. An attacker or an unauthorized user identifies a target path that utilizes Nuxt payload extraction.
5. The attacker issues a GET request to /<target-path>/_payload.json.
6. The Nuxt renderer retrieves the stored payload from the shared cache before any route middleware, page guards, or authorization checks are executed.
7. The sensitive payload, intended only for the original authenticated user, is returned to the unauthorized requester in the response body.

Impact

Successful exploitation leads to unauthorized access to sensitive application data rendered during SSR. This exposure impacts users across different sessions, including the disclosure of profile information, billing details, and internal application data to unauthenticated clients. Any application relying on Nuxt 4.4.0-4.5.0 with caching enabled on authenticated routes is at risk.

Recommendation

• Upgrade to nuxt@4.5.1 immediately to restore proper prerendering gates on payload caching.
• If upgrading is not immediately feasible, set experimental.payloadExtraction: false in the Nuxt configuration to disable the vulnerable endpoint.
• Audit routeRules to remove cache, swr, or isr configurations from pages that display user-specific data.
• Implement authentication requirements at the edge, such as CDN or proxy-level, specifically for /**/_payload.json paths as a temporary defense-in-depth measure.
• Purge CDN and platform caches after applying security updates to ensure potentially leaked payloads are removed from intermediate storage.