Jun 16, 2026·6 min read·4 visits
Nuxt `<NuxtLink>` components prior to versions 3.21.7 and 4.4.7 fail to sanitize URL schemes, enabling DOM-based XSS when binding untrusted, attacker-controlled navigation targets.
A reflected DOM-based Cross-Site Scripting (XSS) vulnerability was identified in Nuxt's core <NuxtLink> component. Prior to the patched versions, the component failed to validate or sanitize the target URI schemes before directly rendering them into the 'href' attribute of native HTML anchor elements. An attacker who controls the input bound to the 'to' or 'href' properties can inject executable URI schemes, such as 'javascript:' or 'data:', leading to arbitrary script execution in the context of the user's browser session.
The <NuxtLink> component is a foundational element within the Nuxt framework used for managing internal and external application navigation. It abstracts Vue Router routing mechanisms and standard native anchor HTML elements. When determining the routing target, <NuxtLink> dynamically evaluates whether the destination is an internal route or an external link.
The attack surface exists when applications dynamically bind untrusted data—such as user-supplied inputs, query parameters, or raw database records—directly to the :to or :href properties of a <NuxtLink> instance. If the bound target is identified as an external address, the framework traditionally rendered the value verbatim.
This behavior results in a Document Object Model (DOM) Cross-Site Scripting vulnerability under CWE-79 (Improper Neutralization of Input During Web Page Generation) and CWE-83 (Improper Neutralization of Script in Attributes). Attackers can execute arbitrary JavaScript payloads within the target browser because browsers natively parse and execute specific URI schemes directly inside anchor attributes.
The underlying technical flaw stems from how <NuxtLink> differentiates between internal and external paths. If a path contains a protocol separator, the framework classifies the routing target as external. Once flagged as external, the framework mapped the raw path string to the rendered native <a> element's href attribute without sanitizing the protocol prefix.
Modern browser rendering engines natively execute executable protocol schemes like javascript:, data:, or vbscript: when a user clicks the respective link. Because the framework assumed all external links were network-based web targets (such as http: or https:), it did not apply standard scheme checks.
An attacker can trigger this condition by supplying a crafted link target containing an active script scheme. The application retrieves this target from state variables or URL search parameters and passes it to <NuxtLink>. This action bypasses default framework-level output escaping because Vue.js considers bindings to attribute fields as secure strings.
In the vulnerable state, external routes were passed directly into the computed path engine. The application resolved path objects and returned them unmodified to the template compiler. The framework omitted sanitization filters at the integration point between the reactive link logic and the native element configuration.
The official security advisory addresses this behavior by introducing sanitizeExternalHref within packages/nuxt/src/app/components/nuxt-link.ts inside commit 0103ce06fbbbdfa079a7f020ef8ce00121eac4a3. The helper utility parses potential targets and rejects executable schemes:
/**
* Reject URL strings that would resolve to a script-capable protocol when used as the
* `href` of an anchor element. Returns the value unchanged when safe, or `null`.
*/
function sanitizeExternalHref (value: string): string | null {
// Strips Unicode control characters and ASCII whitespace
let candidate = value.replace(/[\u0000-\u001f\s]+/g, '')
while (candidate.toLowerCase().startsWith('view-source:')) {
candidate = candidate.slice('view-source:'.length)
}
const colon = candidate.indexOf(':')
if (colon > 0 && isScriptProtocol(candidate.slice(0, colon + 1))) {
return null
}
return value
}This implementation uses isScriptProtocol from the ufo dependency to validate against a protocol blocklist consisting of javascript:, data:, vbscript:, and blob:. If the check fails, the framework sets the computed href property to null and intercepts navigation dynamically:
async navigate (_e?: MouseEvent) {
if (href.value === null) {
if (import.meta.dev) {
console.warn(`[${componentName}] refused to navigate to a URL with a script-capable protocol.`)
}
return;
}
await navigateTo(href.value, { replace: unref(props.replace), external: isExternal.value || hasTarget.value })
}While this sanitization blocks standard exploits, validation bypasses are theoretically possible if downstream parser logic differs from the browser's normalization rules. For example, if the browser normalizes full-width Unicode colons (\uff1a) into standard ASCII colons (:) after the component's scheme check runs, the payload could execute successfully.
To execute this attack, an attacker must locate an application route that parses parameters from the location query or dynamic client state and processes them into <NuxtLink>. The target application pattern usually resembles this layout:
<!-- Vulnerable Application Implementation -->
<template>
<NuxtLink :to="$route.query.continueUrl">Proceed to Destination</NuxtLink>
</template>The attacker crafts a malicious link targeting the vulnerable route, appending the exploit payload as a query parameter. An example exploit string is:
https://example.com/login?continueUrl=javascript:alert(document.domain)
When the victim visits the constructed link and interacts with the navigation anchor, the browser executes the Javascript payload. This execution operates with the privileges of the active session context. A second vector utilizes standard data URIs to execute a same-tab phishing overlay, which replaces the viewport context with a forged authentication prompt:
https://example.com/login?continueUrl=data:text/html,<h1>Session%20Expired</h1>
The security impact of CVE-2026-53722 depends on the session context of the authenticated user. Because the script executes in the context of the application's origin, the attacker can access sensitive client-side data. This includes session tokens stored in localStorage or sessionStorage and browser cookies not flagged with HttpOnly attributes.
An attacker can use this access to capture user inputs, alter page elements, or issue API requests on behalf of the victim. If the vulnerable application handles administrative or backend management tasks, exploitation can lead to administrative account takeover or data exposure.
This vulnerability has been assigned a CVSS v3.1 score of 5.4, reflecting medium severity due to the requirement for user interaction. Its CVSS v4.0 score is 5.1, recognizing the network delivery vector and low complexity, but limiting the severity because it requires active user interaction.
The primary remediation strategy is upgrading the Nuxt framework to patched versions containing the sanitization library. Applications running on the Nuxt 3 branch must upgrade to version 3.21.7 or later. Applications on the Nuxt 4 branch must upgrade to version 4.4.7 or later.
If upgrading is not immediately feasible, developers should implement custom sanitization filters. All dynamic parameters bound to <NuxtLink> components must be validated against an allowlist of permitted target schemes:
function sanitizeRouteInput(target: string): string {
if (!target) return '/'
// Enforce relative paths or standard HTTP/S protocols
const isSafe = /^(https?:\/\/|\/)/i.test(target.trim())
return isSafe ? target : '/'
}Integrate this sanitization function directly into application templates to prevent arbitrary scheme binding:
<NuxtLink :to="sanitizeRouteInput($route.query.continueUrl)">Proceed</NuxtLink>Additionally, implementing a strict Content Security Policy (CSP) with restriction directives such as script-src 'self' and disabling 'unsafe-inline' will mitigate runtime impact if a bypass is discovered.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Nuxt Nuxt | < 3.21.7 | 3.21.7 |
Nuxt Nuxt | >= 4.0.0, < 4.4.7 | 4.4.7 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-79 |
| Attack Vector | Network |
| CVSS Score | 5.4 (Medium) |
| EPSS Score | 0.00198 |
| Impact | Reflected DOM-based Cross-Site Scripting (XSS) |
| Exploit Status | Proof-of-Concept (PoC) |
| KEV Status | Not Listed |
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
A local security vulnerability in the Nuxt development server (nuxt dev) allows local unprivileged users to access sensitive configuration files and source code. On Linux environments running Node.js 20+, Nuxt bound its internal vite-node IPC server to an abstract-namespace Unix socket without any peer authentication, enabling co-resident local users to connect and request module code directly.
Mozilla Bleach is an open-source HTML sanitizing library for Python. Versions up to and including 6.3.0 contain an incomplete filtering implementation in the URI validation logic ('sanitize_uri_value'). This logic fails to detect disallowed protocols, such as 'javascript:', if they contain Unicode invisible characters, whitespace characters, or characters with a code point greater than U+00A0. While standard-compliant web browsers do not directly execute invalid URI schemes containing these non-standard characters, downstream systems that normalize Unicode text by stripping invisible or non-ASCII characters can unintentionally reactivate the 'javascript:' prefix, causing Cross-Site Scripting (XSS). Additionally, this behavior violates Bleach's core sanitization contract by outputting URIs that bypass protocol allowlists configured by the caller.
An uncontrolled resource consumption vulnerability exists in the Python package Bleach when parsing text to linkify email addresses. When `parse_email=True` is enabled, the regular expression engine is forced into a quadratic-time complexity scan on specially crafted payloads lacking an '@' symbol. This causes immediate CPU exhaustion and blocks application server worker processes.
A path traversal and sandbox escape vulnerability in LangChain and LangChain-Anthropic Python packages allows unauthenticated local attackers to access files outside the restricted directory via crafted input, symbolic links, or prefix bypasses.
The PHP Secure Communications Library (phpseclib) contains a Server-Side Request Forgery (SSRF) vulnerability due to an insecure default implementation of Authority Information Access (AIA) certificate chasing. This flaw allows remote, unauthenticated attackers to coerce applications validating user-supplied X.509 certificates into generating arbitrary outbound HTTP requests to internal networks or local interfaces.
A directory traversal vulnerability exists in the Microsoft .NET System.Formats.Tar library during archive extraction. When extracting a TAR archive using the TarFile.ExtractToDirectory API, the extraction engine improperly resolves symbolic links prior to file creation, allowing local unauthorized attackers to write or overwrite arbitrary files outside the target directory. This can lead to local tampering, privilege escalation, or arbitrary code execution.