For many, developers and security experts alike, Cross-site Scripting (XSS) vulnerabilities in modern frontend applications are a solved problem. However, time and time again I find myself learning and discovering new attack vectors and this recent case of Nuxt MDC is exactly such one.

Why Research Nuxt MDC ?

As part of my role as a developer advocate at Snyk, I spent a good amount of time building demo applications that are deliberately vulnerable to security attacks. Specifically in the last couple of years being colored with the rise of LLM use-cases and adoption in many ways from AI-powered code generation to integration of LLM models as part of the AI sauce that powers insights, I’ve been focusing on building fun interactions that make use of GenAI in some way or another.

One of the most popular cases for developers is to integrate with an LLM as part of the i/o of their application interactivity. What’s the prime “hello world” use-case for building LLM-powered applications? A Chatbot! what else :-)

As you can imagine, and probably have experienced already, a Chatbot will need to style and format the text responses. For example, it may respond with bullet points so these need to be properly styled in the web application for a rich user experience. Similarly, it may need to render links, images or render code snippets in a code block. All of those need to be styled by developers.

The LLM itself is often instructed via prompt engineering to always respond in a markdown format, and then developers can utilize various Markdown-to-HTML libraries to render the Markdown response content from the LLM onto the page. This is where the @nuxtjs/mdc library comes into play.

Nuxt MDC (technically the library is named @nuxtjs/mdc) is a community effort to build a Markdown content parser library for Nuxt.js applications. It’s actually quite popularly and widely adopted, spanning about quarter of a million downloads per month from npm.

Nuxt MDC Markdown Content Parser

The following is a simple example of the primary use-case that Nuxt developers would use the Nuxt MDC library for:

import { parseMarkdown } from '@nuxtjs/mdc/runtime';
import { useAsyncData } from '#imports';
let val = `<script type="text/javascript">alert("XSS");</script\>`;
const md = `# Simple Async Example
:async-component
This page contains a simple async component example (above) that simulates async data fetching inside of the \`MDCRenderer\` component.
You can refresh the page to see there are no hydration errors in the console.
Navigate to the [No Async Components page](/async-components/no-async), refresh
`;
const { data: ast } = await useAsyncData<any>(() => parseMarkdown(md));

As you can see from the above code snippet, the parseMarkdown function takes in an input string in Markdown formatting and returns an Abstract Syntax Tree (AST) representation of the passed content string that can then be used to translate the structured content into HTML.

Why is XSS in Nuxt MDC a big deal?

Given that Nuxt applications will be receiving LLM responses in Markdown format and prompt injection is a common attack vector for LLMs, a path is drawn from tricking an LLM to respond with payloads that would be replied by the LLM and would trigger an XSS attack in the Nuxt application.

Consider the following example for such XSS payloads:

- Attempt 1:
[URL](javascript&#58document;alert(1))
- Attempt 3:
<img src="x" onError=alert(1) />
- Attempt 4:
<a href="javascript:alert(1)"> this gets sanitizied, yay!</a>
- Attempt 5:
<IMG onmouseover="alert('xxs')">
- Attempt 6:
<img src="javaSCRIPTmark:alert(1)" />

And as you can see in the screenshot from the Stackblitz’s hosted application running Nuxt and the MDC package, they’re rendered and properly escaped (a little harder to tell, but trust me, none of the above payloads would trigger an alert box in the browser):

You can access this live example on Stackblitz.

Testing Nuxt MDC for XSS Vulnerabilities

So this is how I discovered the XSS vulnerability in the Nuxt MDC library that is now identified as CVE-2025-24981.

An unsafe parsing logic of the URL text that is extracted from markdown content can lead to arbitrary JavaScript code due to a bypass to the existing guards around the javascript: protocol scheme in the URL.

The parsing logic is implemented at /src/runtime/parser/utils/props.ts and maintains a deny-list approach to filtering potential malicious payload. It does so by matching protocol schemes like javascript: and others. Specifically, this is the code from the mdc library’s parser that is not secure enough:

export const unsafeLinkPrefix = [
  'javascript:',
  'data:text/html',
  'vbscript:',
  'data:text/javascript',
  'data:text/vbscript',
  'data:text/css',
  'data:text/plain',
  'data:text/xml'
]
export const validateProp = (attribute: string, value: string) => {
  if (attribute.startsWith('on')) {
    return false
  }
  if (attribute === 'href' || attribute === 'src') {
    return !unsafeLinkPrefix.some(prefix => value.toLowerCase().startsWith(prefix))
  }
  return true
}

Can you see the issue?

The above security guards can be bypassed by an adversarial that provides JavaScript URLs with HTML entities encoded via hex string. Yep, that’s the bypass!

Nuxt MDC XSS Proof of Concept

The following URL payloads if provided to the markdown parsing library (such as through the usage of import { parseMarkdown } from '@nuxtjs/mdc/runtime';) will trigger the alert() dialog:

# ✅ This is correctly escaped by the parser
- XSS Attempt:
<a href="javascript:alert(1)"> this gets sanitizied, yay!</a>
# ❌ These are vulnerable and not escaped
- Bypass 1:
<a href="jav&#x09;ascript:alert('XSS');">Click Me 1</a>
- Bypass 2:
<a href="jav&#x0A;ascript:alert('XSS');">Click Me 2</a>
- Bypass 3:
<a href="jav&#10;ascript:alert('XSS');">Click Me 3</a>

What’s the impact here? Users who consume this library and perform markdown parsing from unvalidated sources such as LLM generative text responses, user input and other untrusted sources could result in rendering vulnerable XSS anchor links.

And so, all versions of @nuxtjs/mdc prior to 0.13.3 are vulnerable to this XSS attack vector with a CVSS rating of critical severity.

The Security Fix

Here’s a TL;DR for a suggested fix to the XSS vulnerability above that was shared with the maintainers of the Nuxt MDC library:

1. Decode the URL
2. Strip HTML entities via the regex
3. Pass this to new URL()
4. Then use new URL() to parse the protocol scheme and only proceed with the URL if it satisfies your allow list (IMO only allow https://). If you however need to maintain some backported compatibility then perhaps at this point of parsing you can continue with the deny-list but it’s less recommended.

I have put forward the described fix in this pull request to the project. It did bring up a few regressions due to the different use-cases of how links are used in different ways in Markdown content, and was followed with a couple more commits to address these regressions.

What should Nuxt developers do next?

Firstly, despite the release of 0.13.3 has been made that fixes this XSS security vulnerability and that has been available for almost a week now, the downloads of the vulnerable versions are still considerably high. This means that many Nuxt applications relying on the MDC library are potentially vulnerable:

Secondly, you should always be cautious and pay a lot of attention to how you render user input or otherwise dynamic data such as that originating from LLM responses. In those cases especially you should carefully review the libraries and the code you depend on to audit that there aren’t weaknesses in security controls that could lead to XSS vulnerabilities.

About Cross-site Scripting (XSS) in Modern Web Applications

I opened this article with the hypothesis that many software developers and security practitioenrs believe that Cross-site Scripting (XSS) vulnerabilities are a security issue of the past. Why? That’s because modern frontend frameworks, spearheaded by React but mostly all of them at this pointed, have adopted built-in security controls such as output escaping and sanitization that addresses JavaScript code injection in the browser.

React for example, uses the JSX syntax to write HTML in JavaScript. If a user input is rendered as part of the JSX template, React will automatically apply output encoding in the form of HTML entities to escape the user input. This is why the following code snippet in React is safe from XSS attacks:

const userInput = '<script>alert("XSS")</script>';
function App() {
  return <div>{userInput}</div>;
}

Svelte, Vue.js and other modern frontend frameworks follow the same principle of secure output escaping by default and provide an escape hatch for developers to render raw HTML if needed. One popular example for that is React’s own dangerouslySetInnerHTML property that can be applied to a component as part of the JSX template.