Vulnerabilities

Vulnerability · GHSA-g2v6-rqmx-r4w6

XSS in @vue/server-renderer via missing CR in attribute-name blacklist

Published Aug 31, 2026 · catalog updated Aug 31, 2026 · XSS in @vue/server-renderer via

Last checked Nov 2, 2026. A connected source was read within the last 7 days.

Open the advisory

Exploitation likelihood is not on this record for GHSA-g2v6-rqmx-r4w6. A missing EPSS score is not a low risk. Compare XSS in @vue/server-renderer via with the linked advisory before you change production.

Severity

High7.2

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Version ranges on file

Affected products

npm @vue/server-renderer

One thing before the technical part -- I know your policy rules out XSS via template expressions, and I want to be clear this isn't that. This isn't about template source at all -- it's about ordinary, documented runtime data binding ( ), where the object's own property keys become HTML attribute names. That's exactly the case exists to guard, and exactly the case exists to make safe for values. I'm not asking you to treat "attacker writes template syntax" as in-scope -- I'm reporting that the guard which is supposed to make untrusted data safe for this documented feature has a gap in it. ## Description I was looking at specifically because it's the one place in Vue where template rendering output becomes a real HTTP response body -- a genuine server-side trust boundary, unlike client-side rendering which only ever affects the same browser session that's already running the app's own JS. (in ) is what compiled SSR output calls for something like . It loops over the object's own keys and, for each one, renders it as an HTML attribute: The value always goes through -- that part is correctly and consistently applied everywhere in this file. But the attribute name ( ) is only checked against a character blacklist, then spliced directly into the output with no escaping of its own: That blacklist covers: , , , , apostrophe, tab (U+0009), line feed (U+000A), form feed (U+000C), and space (U+0020). It does not cover U+000D -- carriage return (CR, written as in JS). That matters because of how browsers actually parse HTML. Per the WHATWG HTML parsing spec, the very first step ("preprocessing the input stream") converts every not followed by into a before the tokenizer even starts. So a raw sitting inside what Vue intends as a single attribute name gets turned into a real line feed by the browser -- and a line feed is one of the characters that terminates an attribute name and starts a new one. The blacklist checks the string as Vue sees it before the browser gets to reinterp