Nuxt EUVD-2026-107417

Exploitation requires ALL of: (1) a Nuxt application in the vulnerable range 3.13.0-4.6.1; (2) use of server islands - a .server.vue component/page or a component rendered through NuxtIsland; (3) application code that passes attacker-controlled data into useHeadSafe within that island (the serialized island response loses the _safe marker, so NuxtIsland re-adds the input as an ordinary head entry and the allowlist no longer strips event-handler attributes or executable script). Limiting factors that reduce realistic risk: the vulnerable useHeadSafe-with-untrusted-data pattern is non-default developer code, not an out-of-the-box behavior; the CVSS PR:L indicates the attacker needs some privilege/ability to store the malicious data; and UI:R means a victim must subsequently load the affected island page for the stored payload to fire.

This is a genuine but conditional, medium-severity stored XSS (CWE-79), not a widespread emergency. The vendor CVSS of 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects network reach but low technical impact (C:L/I:L/A:N) and the need for both low privileges (PR:L) and victim interaction (UI:R). No EPSS score, no CISA KEV listing, and no public exploit were supplied, so the only exploitation signal is the fix commit itself - exploitation status is therefore 'no public exploit identified at time of analysis.' The single most important mitigating factor is not captured by the raw score: the flaw only manifests when a developer deliberately passes attacker-controlled data to useHeadSafe inside a .server.vue component / server island or a NuxtIsland-rendered component. useHeadSafe exists precisely to sanitize such input, so the affected pattern is a security-conscious but mis-trusted coding path rather than a default behavior - I assess AC:H rather than the vendor's AC:L for this reason (see assessed vector). Net: real priority only for Nuxt (3.13.0-4.6.1) applications that use server islands AND feed untrusted data through useHeadSafe; for everyone else this is low real-world risk. No conflicting signals in the data, but the absence of EPSS/KEV/POC means spread cannot be quantified.

An attacker submits a crafted value (e.g. containing an event-handler attribute or script content) through an input that the target Nuxt app forwards to useHeadSafe within a server-island/.server.vue component. Because the server-island renderer drops the safe-input marker, NuxtIsland re-inserts the value into the page head as an ordinary entry, bypassing the allowlist. When another user loads the page, the payload executes as stored XSS in the application origin. No public proof-of-concept was provided; the referenced GitHub link is the remediation commit, not exploit code.