CVE-2026-46342: Nuxt Island Hash Validation Bypass Vulnerability

Technical summary

The /__nuxt_island/* endpoint in affected Nuxt versions implements a hash-based component isolation mechanism for server-side island rendering. The framework generates a hash identifier (<Name>_<hashId>.json) client-side via the <NuxtIsland> component, encoding the component name and a hash derived from the props passed to it. However, the server-side endpoint does not validate that incoming props parameters match the hash; it simply renders the requested island component with whatever props are supplied in the query or request body. This violates the security boundary intended by the hash mechanism—an attacker can call /__nuxt_island/MyComponent?props=attacker_controlled without providing a legitimate hash, or can modify props after the hash was issued, causing the same island path to return materially different responses. The vulnerability is classified under CWE-349 (Improper Restriction of Rendered UI Layers or Frames), CWE-444 (Inconsistent Interpretation of HTTP Requests), and CWE-79 (Improper Neutralization of Input During Web Page Generation—XSS).

Business impact

Organizations running affected Nuxt applications face two primary risks: data leakage and client-side injection attacks. An attacker could craft requests to island endpoints with manipulated props to trigger different server-side behavior, potentially accessing data that should be restricted to other users or sessions. Additionally, if islands render user-controlled or insufficiently sanitized data, the lack of hash validation could lower the barrier to XSS exploitation. While a user interaction is required (the CVSS vector includes UI:R), the practical impact depends on how applications use islands and whether they embed sensitive data or unsanitized user input in component props. Development teams should audit island usage to identify exposure.

Affected systems

Nuxt versions 3.1.0 through 3.21.5 (before patch 3.21.6) and versions 4.0.0-alpha.1 through 4.4.5 (before patch 4.4.6) are affected. The parallel @nuxt/nitro-server package in the same version ranges is also vulnerable. Applications using Nuxt islands for server-side rendering are in scope; applications that do not use the island feature or are running patched versions are not impacted.

Exploitability

The vulnerability requires network access and user interaction to exploit but no authentication or elevated privileges. An attacker can manually craft requests to /__nuxt_island/* endpoints with attacker-controlled props, and if a victim visits a malicious page that makes such requests, the browser will send them on behalf of the user. The low complexity and lack of privilege requirements keep exploitability relatively straightforward, though the requirement for user interaction (clicking a link or visiting a compromised page) adds friction. No public exploit code or active KEV listing was identified at the time of publication.

Remediation

Update Nuxt to version 3.21.6 or later for the 3.x series, or version 4.4.6 or later for the 4.x series. Similarly, update @nuxt/nitro-server to the corresponding patched versions. After upgrading, the framework will validate the hash on the server side, ensuring props match what was originally issued by the client-side component. Verify patches are correctly applied by confirming the version number via package.json or package manager output.

Patch guidance

Prioritize patching for applications that actively use Nuxt islands in production or expose island endpoints to untrusted users. For Nuxt 3.x applications, upgrade to 3.21.6 or later. For Nuxt 4.x applications, upgrade to 4.4.6 or later. Test patches in a staging environment to ensure compatibility; the patch focuses on server-side validation logic and should not break existing legitimate island usage. If using a monorepo or bundled Nuxt setup, confirm that @nuxt/nitro-server is also updated to the matching patched version. Review your package-lock or yarn.lock file to verify no transitive dependencies pin an older version.

Detection guidance

Review application logs for unusual requests to /__nuxt_island/* endpoints, particularly those with query parameters or request bodies that differ significantly from normal usage patterns. Look for repeated or high-volume requests to the same island endpoint with varying props. Implement monitoring on island endpoints to detect when the same island is called with materially different parameters in short time windows—a potential sign of probing or exploitation. During patching, confirm that server-side hash validation is in place by examining the Nuxt source code in node_modules or by enabling verbose logging to trace hash verification in request handling.

Why prioritize this

Although the CVSS score of 5.4 is moderate, the vulnerability should be prioritized for patching within weeks rather than months, especially for publicly facing or multi-tenant Nuxt applications. The attack surface is clear—any application using islands is potentially vulnerable—and the remediation is straightforward (update and test). The requirement for user interaction reduces immediate risk of large-scale automated attacks, but targeted exploitation is plausible. Applications in regulated industries (finance, healthcare) should expedite patching if islands handle sensitive data.

Risk score, explained

The CVSS 3.1 score of 5.4 (MEDIUM) reflects a network-accessible vulnerability with low attack complexity and no privilege requirements, balanced against the requirement for user interaction and limited scope (confidentiality and integrity of data accessed via the island, not system-wide compromise). The vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N indicates an attacker can trigger unintended server responses and potentially extract or modify data, but without denial-of-service or severe data breach impact. In context, organizations relying on islands for security isolation should treat this as elevated priority despite the moderate score.

Frequently asked questions