Jun 16, 2026·6 min read·42 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 critical remote code execution (RCE) vulnerability exists in AWS Amplify Studio's code-generation library (@aws-amplify/codegen-ui). An authenticated attacker with permissions to create or modify component schemas can inject malicious JavaScript code into those schemas. When the Amplify CLI or the build environment processes these schemas, the unvalidated expressions are executed within the host Node.js environment, leading to full system compromise.
CVE-2026-67426 is a critical vulnerability in Flyto2 Core prior to version 2.26.7. The standalone flyto-verification service binds to all interfaces (0.0.0.0) on port 8344 and exposes an unauthenticated POST /run endpoint. This endpoint accepts an arbitrary client-controlled callback URL and makes an outbound POST request containing the sensitive internal runner secret in the headers. Attackers can exploit this to retrieve the FLYTO_RUNNER_SECRET and perform Server-Side Request Forgery (SSRF) against internal network targets.
CVE-2026-66066 (popularly known as 'KindaRails2Shell') is a critical security vulnerability in the Active Storage component of Ruby on Rails. The vulnerability arises from an insecure default integration with the libvips image processing library via the ruby-vips gem. Under default configurations, Active Storage fails to restrict untrusted format loaders within libvips, allowing remote, unauthenticated attackers to upload malformed files that leverage external dataset features to read local server files. By extracting cryptographic secrets such as SECRET_KEY_BASE from the leaked file contents, attackers can forge signed Marshal serialization payloads to achieve remote code execution.
An SSRF validation bypass exists in dssrf-js (v1.0.3 and prior) due to an improper string normalization sequence inside is_url_safe. Before validating the host using Node's WHATWG parser, the helper strips the '@' symbol. This corrupts the parser's authority resolution, while the application's client requests the original, un-sanitized string containing internal IP targets.
A Use-After-Free (UAF) vulnerability exists in msgpack-ruby prior to version 1.8.2. The MessagePack::Buffer#clear method returns the associated 4 KiB rmem page to the shared pool but fails to reset the buffer's tracking pointers (rmem_last, rmem_end, and rmem_owner). Subsequent write operations on the cleared buffer can alias the freed page, allowing concurrent buffers to access, disclose, or corrupt cross-buffer data. This issue is resolved in version 1.8.2.
Flyto2 Core (flyto-core) prior to version 2.26.7 did not utilize its centralized SSRF validation mechanism ('validate_url_with_env_config') across multiple HTTP-emitting modules. This oversight allowed low-privileged users executing automated workflows to perform Server-Side Request Forgery (SSRF) attacks against internal endpoints, loopback interfaces, and cloud provider metadata services.