CVE-2026-63671 is a high-severity (CVSS 8.1) Cross-site Scripting (XSS) vulnerability in @nuxtjs/mdc. A fix is available for @nuxtjs/mdc — see the affected versions and patch details below.
@nuxtjs/mdc: the URL sanitizer misses SVG xlink:href and data:text/html, allowing XSS from untrusted markdown at the default configuration
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-63671.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@nuxtjs/mdcnpmDescription
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @nuxtjs/mdc | all versions | 0.22.1npm install @nuxtjs/mdc@0.22.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nuxtjs/mdc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @nuxtjs/mdc to 0.22.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-63671 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2026-63671 in your dependencies?
Find it across npm, including transitive dependencies.