CVE-2026-114130: Nuxt: Incomplete fix for GHSA-934w-87qh-qr26: a `javascript:` URL prefixed with an ASCII control character executes from `<NuxtLink>` when `pages` is disabled
Impact
An application that renders <NuxtLink :to="..."> with a value it does not control can be made to render an anchor whose href executes script in the application's origin when clicked.
This is an incomplete fix for GHSA-934w-87qh-qr26 (CVE-2026-53722). It only affects applications running without a pages/ directory, where pages resolves to false and Nuxt registers its own router in place of vue-router. Applications using vue-router are not affected.
Prefixing javascript: with an ASCII C0 control character, for example %01, meant the value was not recognised as having a protocol. It was classified as an internal route and so never reached the protocol check added in GHSA-934w-87qh-qr26, and the router used for pages: false passed it through to the rendered href unchanged. Browsers strip the leading control character and run the result as a script URL.
Both <NuxtLink custom> and the default anchor are affected, and the href is present in the server-rendered HTML.
Mitigating factors
- The application must have pages disabled (no pages/ directory, or pages: false). - The application must bind untrusted input to :to. - A victim must click the rendered link.
Affected versions
nuxt <4.6.0, including all Nuxt 3 releases. Versions before 4.4.7 and 3.21.7 are also affected by GHSA-934w-87qh-qr26.
Patches
Fixed in nuxt@4.6.0. Nuxt 3 reached end of life on 31 July 2026 and will not receive a fix.
Anchor href values are now checked for script-capable protocols wherever they are rendered, including the router used when pages is disabled. Protocol detection also moved to the platform URL parser, so a URL is classified the same way the browser will read it.
Workarounds
Upgrade to nuxt@4.6.0 or later. If you cannot upgrade, including on Nuxt 3, validate values before binding them to :to, for example by rejecting anything that is not a path beginning with a single /.
Other sources
Nuxt is an open-source web development framework for Vue.js. Prior to 4.6.0, an incomplete fix for CVE-2026-53722 allows an application with pages disabled to render a script-capable URL through NuxtLink when attacker-controlled input bound to to is prefixed with an ASCII C0 control character. The no-pages router classifies the value as an internal route before the earlier protocol check and passes it to the rendered anchor href; browsers remove the leading control character and interpret the remaining javascript: URL. The default anchor and NuxtLink custom output are affected, the unsafe href is present in server-rendered HTML, and a victim must click the link for script to execute in the application's origin. This issue is fixed in version 4.6.0.
— 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.0 - Upgrade
Upgrade
nuxtto a version that resolves this vulnerability.Fixed in 4.6.0 - Compensating control
If upgrading is not possible, validate values before binding them to NuxtLink :to by rejecting anything that is not a path beginning with a single /.
Event History
Frequently Asked Questions
Which Nuxt applications are exposed?
Applications using Nuxt versions before 4.6.0 are affected when pages is disabled and attacker-controlled input is bound to a NuxtLink to value. Both the default anchor output and NuxtLink custom output are affected.
What must happen for exploitation?
An attacker must supply a javascript: URL prefixed with an ASCII C0 control character into the to value. A victim must then click the rendered link; the script executes in the application's origin.
Is the unsafe value visible before a user clicks it?
Yes. The unsafe href is present in server-rendered HTML, so rendered output can be inspected for href values that begin with an ASCII control character followed by javascript:.
What version fixes the issue?
Upgrade Nuxt to version 4.6.0. The issue affects versions prior to 4.6.0.