@nuxtjs/mdc's URL sanitizer misses SVG xlink:href and data:text/html, allowing XSS from untrusted markdown at the default configuration
🔗 CVE IDs covered (1)
📋 Description
Summary
@nuxtjs/mdc renders untrusted markdown (including raw HTML) to a Vue component tree. Across two prior advisories it added a URL/attribute sanitizer to block dangerous links in that HTML: validateProps / validateProp and an unsafeLinkPrefix deny-list (dist/runtime/parser/utils/props.js). The sanitizer runs at parse time (dist/runtime/parser/compiler.js) and parseMarkdown enables raw HTML by default (allowDangerousHtml: true, dist/runtime/parser/options.js), so the sanitizer is the only barrier and it applies with no configuration required.
Two sibling vectors bypass that sanitizer at the default configuration:
-
SVG anchor
xlink:href.validateProponly scheme-checks attributes named exactlyhreforsrc:if (attribute === "href" || attribute === "src") return isAnchorLinkAllowed(value); return true;An
xlink:href(parsed to the hast propertyxLinkHref) is neither, so ajavascript:URL on an SVG<a>is passed through. The renderer maps the property back to the real attribute (MDCRenderer.vue:find(html, "xLinkHref").attributeisxlink:href), so the output element is<a xlink:href="javascript:...">. Clicking it runs the script in the page origin. Plain<a href="javascript:...">is correctly stripped, which is what makes this the un-patched sibling. -
<iframe src="data:text/html,...">.data:text/htmlis present inunsafeLinkPrefix, but the check compares it againsturl.protocol:if (unsafeLinkPrefix.some((prefix) => url.protocol.toLowerCase().startsWith(prefix))) return false;For any data URI
url.protocolis just"data:", so"data:".startsWith("data:text/html")is always false. Everydata:text/*entry in the deny-list is therefore dead code, and<iframe src="data:text/html,<script>...</script>">is allowed (iframe is not in the render-timedangerousTags, which is only["script","base"]). The framed document executes script in an opaque origin. For contrast,srcdocandobjectare blocked, so this is a precise gap rather than a general absence of filtering.
Reproduction
I will attach the zip file for POC, you can simply extract and run ./poc.sh to install mdc and show the poc in the html file.
nuxtjs-mdc-xss_poc.zip
Two zero-argument checks:
sh poc/poc.shinstalls@nuxtjs/mdcand runsparseMarkdown(the documented API) at default. It shows the parsed tree retainsa { xLinkHref: "javascript:..." }andiframe { src: "data:text/html,..." }, while the control payloadshref="javascript:..."andsrcdoc=...are removed by the sanitizer. This isolates the sanitizer bypass deterministically.poc/poc.shalso servespoc/poc.htmlover http (data: iframes and javascript: links are restricted under the file:// origin, so http is used). Open the printed URL and click the blue SVG link. The page contains the exact DOM the renderer produces for those parsed nodes; clicking the SVG link executes script in the page origin (same-origin), and the data:text/html iframe executes on load. The page prints VULNERABLE for each that fires.
Both vectors were confirmed executing in a current Chromium build: the SVG xlink:href link runs script in the document origin on click, and the data:text/html iframe runs script on load.
Suggested fix
In validateProp, scheme-check xlink:href (and the hast xLinkHref) the same way as href/src. In isAnchorLinkAllowed, compare the dangerous MIME-typed entries against the full URL (or href), not against url.protocol, so data:text/html is actually matched; or add iframe to the render-time dangerous-tag set / restrict iframe src schemes.
🎯 Affected products1
- npm/@nuxtjs/mdc:< 0.22.1
🔗 References (6)
- https://github.com/nuxt-content/mdc/security/advisories/GHSA-mxm6-v9r6-r94c
- https://nvd.nist.gov/vuln/detail/CVE-2026-63671
- https://github.com/nuxt-content/mdc/pull/491
- https://github.com/nuxt-content/mdc/commit/61d636c2983f021288e4fc5c4006733b38cf0d53
- https://github.com/nuxt-content/mdc/releases/tag/v0.22.1
- https://github.com/advisories/GHSA-mxm6-v9r6-r94c