CVE-2026-114133: Nuxt server islands render `useHeadSafe` input without sanitisation
Impact
useHeadSafe restricts head input to an allowlist of safe tags and attributes. For example, bodyAttrs is limited to class and style, event handler attributes are removed, and <script> tags are only kept for JSON types.
When useHeadSafe is called inside a server island (a .server.vue component or page, or a component rendered with <NuxtIsland>), the island renderer serialises the raw input of every head entry into the island response without the option that marks it as safe input. <NuxtIsland> then pushes that input into the page's head as a regular entry, both during server rendering and when hydrating or refetching on the client.
As a result, input that useHeadSafe would normally strip (such as bodyAttrs.onload or executable <script> content) is rendered into the page. If an application passes user-controlled data to useHeadSafe inside a server island, an attacker who controls that data can achieve stored cross-site scripting on the application's origin.
vue <!-- components/AuthorMeta.server.vue --> <script setup lang="ts"> const { data: author } = await useFetch('/api/author') // author.value.head is user-authored, e.g. { bodyAttrs: { onload: '...' } } useHeadSafe(author.value.head) </script>
Mitigating factors
- Server components are experimental. They are only active when the application defines a .server.vue component or page, or enables experimental.componentIslands and renders <NuxtIsland>. - Exploitation requires the application to pass attacker-controlled data to useHeadSafe inside a server island. useHeadSafe called from regular (non-island) components and pages is not affected.
Affected versions
nuxt >=3.13.0, when head support for server islands was introduced. Nuxt 2 is not affected.
Patches
Fixed in nuxt@4.6.2. Nuxt 3 reached end of life on 31 July 2026 and will not receive a fix.
Patched releases apply Unhead's safe input filtering to useHeadSafe entries on the server before they are added to the island response, so islandResponse.head (including what render:island hooks see) only contains input that useHeadSafe allows.
Workarounds
Upgrade to nuxt@4.6.2. If you cannot upgrade, including on Nuxt 3:
1. Call useHeadSafe with untrusted input from a regular component or page rather than from inside a server island. 2. Alternatively, validate untrusted head input against your own allowlist before passing it to useHeadSafe inside a server island.
Other sources
Nuxt is an open-source web development framework for Vue.js. From 3.13.0 until 4.6.2, the server-island renderer serializes raw useHeadSafe entry input into the island response without preserving the safe-input marker, and NuxtIsland later inserts that input into the page head as an ordinary entry. An application that passes attacker-controlled data to useHeadSafe in a .server.vue component or page, or in a component rendered through NuxtIsland, can therefore render values normally removed by the allowlist, including event-handler attributes or executable script content, resulting in stored cross-site scripting in the application origin. This issue is fixed in version 4.6.2 .
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/nuxtto a version that resolves this vulnerability.Fixed in 4.6.2 - Upgrade
Upgrade
nuxtto a version that resolves this vulnerability.Fixed in 4.6.2 - Compensating control
If upgrading is not possible, do not call useHeadSafe with untrusted input inside a server island; call it from a regular component or page, or validate untrusted head input against an application-specific allowlist before passing it to useHeadSafe inside a server island.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires an application to pass attacker-controlled data to useHeadSafe in a .server.vue component or page, or in a component rendered through NuxtIsland. The affected behavior is described for Nuxt versions from 3.13.0 until the fix in 4.6.2.
What attacker-controlled content can lead to impact?
An attacker needs to control data supplied to useHeadSafe in one of the affected rendering paths. The server-island response can then cause values normally removed by the allowlist, including event-handler attributes or executable script content, to be inserted into the page head and produce stored cross-site scripting.
How can I identify potentially affected application code?
Review uses of useHeadSafe in .server.vue components and pages, and in components rendered through NuxtIsland. Prioritize any call sites whose input can originate from untrusted or user-controlled stored data.