CWE-91
Allowed-with-ReviewXML Injection (aka Blind XPath Injection)
Abstraction: Base · Status: Draft
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
216 vulnerabilities reference this CWE, most recent first.
GHSA-4W3W-2RP5-G8JM
Vulnerability from github – Published: 2026-09-08 20:30 – Updated: 2026-09-08 20:30Summary
Element.setAttribute() in @xmldom/xmldom bypasses attribute name validation by calling the private _createAttribute(name) method, which performs no validation. The public createAttribute() method correctly validates names against an anchored QName pattern, but setAttribute() never uses it. The serializer escapes attribute values but trusts attribute names, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The requireWellFormed: true option did not catch this.
Details
Element.setAttribute(name, value) creates attribute nodes by calling the private _createAttribute(name) method, which performs no validation on the name parameter. In contrast, the public Document.createAttribute(name) method validates the name against the QName production before creating the attribute node.
The result is a two-tier validation system where the most commonly used API (setAttribute) takes the unvalidated path:
doc.createAttribute("bad name")— throwsINVALID_CHARACTER_ERR(correct).el.setAttribute("bad name", "value")— succeeds silently (vulnerable).
The serializer emits attribute names verbatim into the output. Because attribute values ARE escaped (quotes, ampersands, etc.), the injection must occur through the name. An attacker can terminate the current attribute and inject new ones by including quote and space characters in the attribute name.
Root Cause
setAttribute()calls_createAttribute()(private, no validation) instead ofcreateAttribute()(public, validates againstQName).- The serializer trusts attribute names and emits them unescaped.
- The serializer's
requireWellFormedcode path did not validate attribute names during serialization.
Proof of Concept
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// The attribute name contains a closing quote, a space, and a new attribute
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// <root class="safe" onclick="alert(1)"/>
//
// The single setAttribute() call produced TWO attributes:
// 1. class="safe"
// 2. onclick="alert(1)"
//
// requireWellFormed: true did NOT prevent the injection.
Demonstrating the validation gap
// Public createAttribute correctly rejects invalid names:
try {
doc.createAttribute('class="safe" onclick');
} catch (e) {
console.log('createAttribute rejects:', e.message);
}
// But setAttribute (which uses _createAttribute) accepts the same input:
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
// No error thrown
Impact
Applications that use setAttribute() with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:
- Cross-Site Scripting (XSS): Injecting event handler attributes into HTML output consumed by browsers.
- Security attribute override: Overriding security-relevant attributes such as
integrity,nonce,sandbox, orContent-Security-Policymeta attributes. - Validation bypass: The public
createAttribute()API validates whilesetAttribute()does not, creating an inconsistent security boundary that developers cannot rely on. - requireWellFormed bypass: Applications that adopted
requireWellFormed: trueas a mitigation for prior CVEs remained vulnerable.
@xmldom/xmldom can also be used inside browsers, where it mirrors the DOM API. Unlike the browser's setAttribute(), which rejects an invalid attribute name with InvalidCharacterError, xmldom accepts it — developers may assume the same safety and skip validation.
Fix Applied
⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain vulnerable unless
{ requireWellFormed: true }is explicitly passed. Applications that serialize untrusted DOM content should audit allserializeToString()call sites and add it.
When { requireWellFormed: true } is passed, the serializer now validates each serialized attribute's qualified name against the XML QName production and throws InvalidStateError before emitting it. This covers ordinary attribute names and synthesized xmlns:PREFIX namespace declarations (the namespace-prefix sub-vector).
Fixed under requireWellFormed: true in @xmldom/xmldom 0.9.11 and 0.8.14. Default serialization is unchanged.
PoC — fixed path
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
// Default (unchanged): verbatim — injection present
console.log(new XMLSerializer().serializeToString(doc));
// <root class="safe" onclick="alert(1)"/>
// Opt-in guard: throws InvalidStateError before serializing
try {
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
console.log(e.name, e.message);
// InvalidStateError: The attribute name "class="safe" onclick" is not a valid XML QName
}
Why the default stays verbatim
The W3C DOM Parsing and Serialization spec defines a require well-formed flag whose default value is false. With the flag unset, the serializer emits attribute names verbatim, matching the XMLSerializer behavior of Chrome, Firefox, and Safari. Unconditionally throwing would be a behavioral breaking change with no spec justification; the opt-in requireWellFormed: true flag lets applications that require injection safety enable strict mode without breaking existing code.
Residual limitation
setAttribute(name, value) does not validate name at creation time (unlike the public createAttribute(), which already does). Making setAttribute() reject invalid names unconditionally is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without requireWellFormed: true), attribute names set via setAttribute() are still emitted verbatim; applications that do not pass requireWellFormed: true remain exposed.
Creation-time validation is tracked in a public issue on the next breaking-release milestone (filed at publication — issue link to be added), targeting the next breaking release.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.10"
},
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.13"
},
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.0"
},
{
"fixed": "0.8.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-83605"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:30:51Z",
"nvd_published_at": "2026-09-01T15:17:38Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Element.setAttribute()` in `@xmldom/xmldom` bypasses attribute name validation by calling the private `_createAttribute(name)` method, which performs no validation. The public `createAttribute()` method correctly validates names against an anchored `QName` pattern, but `setAttribute()` never uses it. The serializer escapes attribute *values* but trusts attribute *names*, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The `requireWellFormed: true` option did not catch this.\n\n## Details\n\n`Element.setAttribute(name, value)` creates attribute nodes by calling the private `_createAttribute(name)` method, which performs no validation on the `name` parameter. In contrast, the public `Document.createAttribute(name)` method validates the name against the `QName` production before creating the attribute node.\n\nThe result is a two-tier validation system where the most commonly used API (`setAttribute`) takes the unvalidated path:\n\n- `doc.createAttribute(\"bad name\")` \u2014 throws `INVALID_CHARACTER_ERR` (correct).\n- `el.setAttribute(\"bad name\", \"value\")` \u2014 succeeds silently (vulnerable).\n\nThe serializer emits attribute names verbatim into the output. Because attribute values ARE escaped (quotes, ampersands, etc.), the injection must occur through the name. An attacker can terminate the current attribute and inject new ones by including quote and space characters in the attribute name.\n\n### Root Cause\n\n1. `setAttribute()` calls `_createAttribute()` (private, no validation) instead of `createAttribute()` (public, validates against `QName`).\n2. The serializer trusts attribute names and emits them unescaped.\n3. The serializer\u0027s `requireWellFormed` code path did not validate attribute names during serialization.\n\n## Proof of Concept\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst impl = new DOMImplementation();\nconst serializer = new XMLSerializer();\nconst doc = impl.createDocument(null, \u0027root\u0027, null);\n\n// The attribute name contains a closing quote, a space, and a new attribute\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n\nconst output = serializer.serializeToString(doc, { requireWellFormed: true });\nconsole.log(output);\n// \u003croot class=\"safe\" onclick=\"alert(1)\"/\u003e\n//\n// The single setAttribute() call produced TWO attributes:\n// 1. class=\"safe\"\n// 2. onclick=\"alert(1)\"\n//\n// requireWellFormed: true did NOT prevent the injection.\n```\n\n### Demonstrating the validation gap\n\n```js\n// Public createAttribute correctly rejects invalid names:\ntry {\n doc.createAttribute(\u0027class=\"safe\" onclick\u0027);\n} catch (e) {\n console.log(\u0027createAttribute rejects:\u0027, e.message);\n}\n\n// But setAttribute (which uses _createAttribute) accepts the same input:\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n// No error thrown\n```\n\n## Impact\n\nApplications that use `setAttribute()` with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:\n\n- **Cross-Site Scripting (XSS)**: Injecting event handler attributes into HTML output consumed by browsers.\n- **Security attribute override**: Overriding security-relevant attributes such as `integrity`, `nonce`, `sandbox`, or `Content-Security-Policy` meta attributes.\n- **Validation bypass**: The public `createAttribute()` API validates while `setAttribute()` does not, creating an inconsistent security boundary that developers cannot rely on.\n- **requireWellFormed bypass**: Applications that adopted `requireWellFormed: true` as a mitigation for prior CVEs remained vulnerable.\n\n`@xmldom/xmldom` can also be used inside browsers, where it mirrors the DOM API. Unlike the browser\u0027s `setAttribute()`, which rejects an invalid attribute name with `InvalidCharacterError`, xmldom accepts it \u2014 developers may assume the same safety and skip validation.\n\n## Fix Applied\n\n\u003e **\u26a0 Opt-in required.** Protection is not automatic. Existing serialization calls remain\n\u003e vulnerable unless `{ requireWellFormed: true }` is explicitly passed. Applications that\n\u003e serialize untrusted DOM content should audit all `serializeToString()` call sites and add it.\n\nWhen `{ requireWellFormed: true }` is passed, the serializer now validates each serialized attribute\u0027s qualified name against the XML `QName` production and throws `InvalidStateError` before emitting it. This covers ordinary attribute names **and** synthesized `xmlns:PREFIX` namespace declarations (the namespace-prefix sub-vector).\n\nFixed under `requireWellFormed: true` in `@xmldom/xmldom` **0.9.11** and **0.8.14**. Default serialization is unchanged.\n\n### PoC \u2014 fixed path\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst doc = new DOMImplementation().createDocument(null, \u0027root\u0027, null);\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n\n// Default (unchanged): verbatim \u2014 injection present\nconsole.log(new XMLSerializer().serializeToString(doc));\n// \u003croot class=\"safe\" onclick=\"alert(1)\"/\u003e\n\n// Opt-in guard: throws InvalidStateError before serializing\ntry {\n new XMLSerializer().serializeToString(doc, { requireWellFormed: true });\n} catch (e) {\n console.log(e.name, e.message);\n // InvalidStateError: The attribute name \"class=\"safe\" onclick\" is not a valid XML QName\n}\n```\n\n### Why the default stays verbatim\n\nThe W3C DOM Parsing and Serialization spec defines a `require well-formed` flag whose **default value is `false`**. With the flag unset, the serializer emits attribute names verbatim, matching the `XMLSerializer` behavior of Chrome, Firefox, and Safari. Unconditionally throwing would be a behavioral breaking change with no spec justification; the opt-in `requireWellFormed: true` flag lets applications that require injection safety enable strict mode without breaking existing code.\n\n### Residual limitation\n\n`setAttribute(name, value)` does not validate `name` at creation time (unlike the public `createAttribute()`, which already does). Making `setAttribute()` reject invalid names unconditionally is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without `requireWellFormed: true`), attribute names set via `setAttribute()` are still emitted verbatim; applications that do not pass `requireWellFormed: true` remain exposed.\n\nCreation-time validation is tracked in a public issue on the next breaking-release milestone (filed at publication \u2014 issue link to be added), targeting the next breaking release.",
"id": "GHSA-4w3w-2rp5-g8jm",
"modified": "2026-09-08T20:30:51Z",
"published": "2026-09-08T20:30:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-4w3w-2rp5-g8jm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83605"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/pull/1043"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/pull/1050"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/cba1321218b069182695813fa7565653708e172e"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/d8212e632507eaf1d9f609657dd4c56abeb12d44"
},
{
"type": "PACKAGE",
"url": "https://github.com/xmldom/xmldom"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.8.14"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.9.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed"
}
GHSA-4X28-F32Q-R2QV
Vulnerability from github – Published: 2025-10-21 12:31 – Updated: 2025-10-23 15:30Zohocorp ManageEngine EndPoint Central versions 11.4.2516.1 and prior are vulnerable to XML Injection.
{
"affected": [],
"aliases": [
"CVE-2025-7473"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-21T11:15:34Z",
"severity": "MODERATE"
},
"details": "Zohocorp ManageEngine EndPoint Central versions\u00a011.4.2516.1 and prior are vulnerable to XML Injection.",
"id": "GHSA-4x28-f32q-r2qv",
"modified": "2025-10-23T15:30:31Z",
"published": "2025-10-21T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7473"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/desktop-central/parsing-xml-data.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-536H-WXCG-VP88
Vulnerability from github – Published: 2024-11-27 00:31 – Updated: 2024-11-27 00:31An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.
{
"affected": [],
"aliases": [
"CVE-2024-11622"
],
"database_specific": {
"cwe_ids": [
"CWE-611",
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-26T22:15:17Z",
"severity": "HIGH"
},
"details": "An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.",
"id": "GHSA-536h-wxcg-vp88",
"modified": "2024-11-27T00:31:41Z",
"published": "2024-11-27T00:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11622"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04731en_us"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-56G4-WF8M-979X
Vulnerability from github – Published: 2024-11-27 00:31 – Updated: 2024-11-27 00:31An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.
{
"affected": [],
"aliases": [
"CVE-2024-53675"
],
"database_specific": {
"cwe_ids": [
"CWE-611",
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-26T22:15:18Z",
"severity": "HIGH"
},
"details": "An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.",
"id": "GHSA-56g4-wf8m-979x",
"modified": "2024-11-27T00:31:41Z",
"published": "2024-11-27T00:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53675"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04731en_us"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-5CX9-PQMM-54RV
Vulnerability from github – Published: 2022-05-17 03:13 – Updated: 2022-05-17 03:13IBM BigFix Remote Control before 9.1.3 allows remote attackers to conduct XML injection attacks via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2016-2932"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-30T11:59:00Z",
"severity": "MODERATE"
},
"details": "IBM BigFix Remote Control before 9.1.3 allows remote attackers to conduct XML injection attacks via unspecified vectors.",
"id": "GHSA-5cx9-pqmm-54rv",
"modified": "2022-05-17T03:13:19Z",
"published": "2022-05-17T03:13:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-2932"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg1IV89787"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21991882"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94983"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5HR6-VC97-QXXH
Vulnerability from github – Published: 2022-02-09 23:08 – Updated: 2021-04-13 17:51Crafter CMS Crafter Studio 3.0.1 is affected by: XML External Entity (XXE). An unauthenticated attacker is able to create a site with specially crafted XML that allows the retrieval of OS files out-of-band.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.craftercms:crafter-studio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-15685"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-13T17:51:27Z",
"nvd_published_at": "2020-11-27T18:15:00Z",
"severity": "HIGH"
},
"details": "Crafter CMS Crafter Studio 3.0.1 is affected by: XML External Entity (XXE). An unauthenticated attacker is able to create a site with specially crafted XML that allows the retrieval of OS files out-of-band.",
"id": "GHSA-5hr6-vc97-qxxh",
"modified": "2021-04-13T17:51:27Z",
"published": "2022-02-09T23:08:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15685"
},
{
"type": "WEB",
"url": "https://docs.craftercms.org/en/3.0/security/advisory.html"
},
{
"type": "WEB",
"url": "http://crafter.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "XML Injection in Crafter CMS Crafter Studio 3.0.1"
}
GHSA-5JCC-2J97-XPCF
Vulnerability from github – Published: 2026-03-04 09:31 – Updated: 2026-03-09 18:31Improper neutralization of special elements in the /IDC_Logging/checkifdone.cgi script in International Datacasting Corporation (IDC) SFX Series SuperFlex Satellite Receiver Web management Interface version 101 allows for XML Injection. The application reflects un-sanitized user input from the file parameter directly into a CDATA block, allowing an authenticated attacker to break out of the tags and inject arbitrary XML elements. An actor is confirmed to be able to turn this into an reflected XSS but further abuse such as XXE may be possible
{
"affected": [],
"aliases": [
"CVE-2026-28770"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T07:16:14Z",
"severity": "MODERATE"
},
"details": "Improper neutralization of special elements in the /IDC_Logging/checkifdone.cgi script in International Datacasting Corporation (IDC) SFX Series SuperFlex Satellite Receiver Web management Interface version 101 allows for XML Injection. The application reflects un-sanitized user input from the `file` parameter directly into a CDATA block, allowing an authenticated attacker to break out of the tags and inject arbitrary XML elements. An actor is confirmed to be able to turn this into an reflected XSS but further abuse such as XXE may be possible",
"id": "GHSA-5jcc-2j97-xpcf",
"modified": "2026-03-09T18:31:36Z",
"published": "2026-03-04T09:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28770"
},
{
"type": "WEB",
"url": "https://www.abdulmhsblog.com/posts/sfx2100-vulns"
},
{
"type": "WEB",
"url": "https://www.abdulmhsblog.com/posts/spfx-vulnrabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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-5P4V-RPM8-M6G3
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:09Due to missing input validation, SAP Financial Consolidation, before versions 10.0 and 10.1, enables an attacker to use crafted input to interfere with the structure of the surrounding query leading to XPath Injection.
{
"affected": [],
"aliases": [
"CVE-2019-0370"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-08T20:15:00Z",
"severity": "MODERATE"
},
"details": "Due to missing input validation, SAP Financial Consolidation, before versions 10.0 and 10.1, enables an attacker to use crafted input to interfere with the structure of the surrounding query leading to XPath Injection.",
"id": "GHSA-5p4v-rpm8-m6g3",
"modified": "2024-04-04T02:09:32Z",
"published": "2022-05-24T16:57:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0370"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2806403"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=528123050"
}
],
"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"
}
]
}
GHSA-5PJJ-7FQ8-9GPF
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2025-11-07 23:16Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an XML Injection vulnerability when saving a configurable product. An attacker with admin privileges can trigger a specially crafted script to achieve remote code execution.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/project-community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.7-p1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.3.7"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.2-p1"
},
{
"fixed": "2.4.2-p2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.2"
]
}
],
"aliases": [
"CVE-2021-36028"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-07T23:16:16Z",
"nvd_published_at": "2021-09-01T15:15:00Z",
"severity": "CRITICAL"
},
"details": "Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an XML Injection vulnerability when saving a configurable product. An attacker with admin privileges can trigger a specially crafted script to achieve remote code execution.",
"id": "GHSA-5pjj-7fq8-9gpf",
"modified": "2025-11-07T23:16:16Z",
"published": "2022-05-24T19:12:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36028"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb21-64.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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": "Magento has an XML Injection vulnerability"
}
GHSA-5WM8-GMM8-39J9
Vulnerability from github – Published: 2026-05-08 16:29 – Updated: 2026-05-14 20:37Summary
When an input data has quotes in attribute values but process entities is not enabled, it breaks the attribute value into multiple attributes. This gives the room for an attacker to insert unwanted attributes to the XML/HTML.
Detail
Malicious Input
{
a: {
"@_attr": '" onClick="alert(1)'
}
}
Output
<a attr="" onClick="alert(1)"></a>
Workarounds
If you're not ignoring attributes then keep processEntities flag true.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.6"
},
"package": {
"ecosystem": "npm",
"name": "fast-xml-builder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44665"
],
"database_specific": {
"cwe_ids": [
"CWE-611",
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T16:29:10Z",
"nvd_published_at": "2026-05-13T16:16:59Z",
"severity": "HIGH"
},
"details": "# Summary\nWhen an input data has quotes in attribute values but process entities is not enabled, it breaks the attribute value into multiple attributes. This gives the room for an attacker to insert unwanted attributes to the XML/HTML.\n\n## Detail\n\nMalicious Input\n```\n{\n a: {\n \"@_attr\": \u0027\" onClick=\"alert(1)\u0027\n }\n}\n```\n\nOutput\n```xml\n\u003ca attr=\"\" onClick=\"alert(1)\"\u003e\u003c/a\u003e\n```\n\n### Workarounds\nIf you\u0027re not ignoring attributes then keep processEntities flag true.",
"id": "GHSA-5wm8-gmm8-39j9",
"modified": "2026-05-14T20:37:36Z",
"published": "2026-05-08T16:29:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-builder/security/advisories/GHSA-5wm8-gmm8-39j9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44665"
},
{
"type": "PACKAGE",
"url": "https://github.com/NaturalIntelligence/fast-xml-builder"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "fast-xml-builder allows attribute values with unwanted quotes to bypass malicious or unwanted attributes"
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
CAPEC-250: XML Injection
An attacker utilizes crafted XML user-controllable input to probe, attack, and inject data into the XML database, using techniques similar to SQL injection. The user-controllable input can allow for unauthorized viewing of data, bypassing authentication or the front-end application for direct XML database access, and possibly altering database information.
CAPEC-83: XPath Injection
An attacker can craft special user-controllable input consisting of XPath expressions to inject the XML database and bypass authentication or glean information that they normally would not be able to. XPath Injection enables an attacker to talk directly to the XML database, thus bypassing the application completely. XPath Injection results from the failure of an application to properly sanitize input used as part of dynamic XPath expressions used to query an XML database.