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.
190 vulnerabilities reference this CWE, most recent first.
GHSA-W53C-VMPF-RRJ7
Vulnerability from github – Published: 2022-05-14 03:02 – Updated: 2022-05-14 03:02Openpsa contains a XML Injection vulnerability in RSS file upload feature that can result in Remote denial of service. This attack appear to be exploitable via Specially crafted XML file. This vulnerability appears to have been fixed in after commit 4974a26.
{
"affected": [],
"aliases": [
"CVE-2018-1000526"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-26T16:29:00Z",
"severity": "HIGH"
},
"details": "Openpsa contains a XML Injection vulnerability in RSS file upload feature that can result in Remote denial of service. This attack appear to be exploitable via Specially crafted XML file. This vulnerability appears to have been fixed in after commit 4974a26.",
"id": "GHSA-w53c-vmpf-rrj7",
"modified": "2022-05-14T03:02:50Z",
"published": "2022-05-14T03:02:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000526"
},
{
"type": "WEB",
"url": "https://github.com/flack/openpsa/issues/192"
},
{
"type": "WEB",
"url": "https://0dd.zone/2018/05/31/OpenPSA-Object-Injection"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WH42-8R2W-873X
Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2025-03-04 18:03Adobe Commerce versions 2.4.6 (and earlier), 2.4.5-p2 (and earlier) and 2.4.4-p3 (and earlier) are affected by an XML Injection vulnerability. An attacker with low privileges can trigger a specially crafted script to a security feature bypass. Exploitation of this issue does not require user interaction.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.6"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.5"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.4"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.5-p1"
},
{
"fixed": "2.4.5-p3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.4-p1"
},
{
"fixed": "2.4.4-p4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/project-community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29289"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-04T18:02:59Z",
"nvd_published_at": "2023-06-15T19:15:10Z",
"severity": "MODERATE"
},
"details": "Adobe Commerce versions 2.4.6 (and earlier), 2.4.5-p2 (and earlier) and 2.4.4-p3 (and earlier) are affected by an XML Injection vulnerability. An attacker with low privileges can trigger a specially crafted script to a security feature bypass. Exploitation of this issue does not require user interaction.",
"id": "GHSA-wh42-8r2w-873x",
"modified": "2025-03-04T18:03:00Z",
"published": "2023-06-15T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29289"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb23-35.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Magento Open Source allows XML Injection"
}
GHSA-WH4C-J3R5-MJHP
Vulnerability from github – Published: 2026-04-01 00:19 – Updated: 2026-04-24 23:17Summary
@xmldom/xmldom allows attacker-controlled strings containing the CDATA terminator ]]> to be inserted into a CDATASection node. During serialization, XMLSerializer emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became active XML markup in the serialized output, enabling XML structure
injection and downstream business-logic manipulation.
The sequence ]]> is not allowed inside CDATA content and must be rejected or safely handled during serialization. (MDN Web Docs)
Attack surface
Document.createCDATASection(data) is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate ]]> in mutation methods — only createCDATASection carries that guard. The following paths therefore also allow ]]> to enter a CDATASection node and reach the serializer:
CharacterData.appendData()CharacterData.replaceData()CharacterData.insertData()- Direct assignment to
.data - Direct assignment to
.textContent
(Note: assigning to .nodeValue does not update .data in this implementation — the serializer reads .data directly — so .nodeValue is not an exploitable path.)
Parse path
Parsing XML that contains a CDATA section is not affected. The SAX parser's non-greedy CDSect regex stops at the first ]]>, so parsed CDATA data never contains the terminator.
Impact
If an application uses xmldom to generate "trusted" XML documents that embed untrusted user input inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document.
This can lead to:
- Integrity violation of generated XML documents.
- Business-logic injection in downstream consumers (e.g., injecting
<approved>true</approved>,<role>admin</role>, workflow flags, or other security-relevant elements). - Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear.
This issue does not require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup.
Root Cause (with file + line numbers)
File: lib/dom.js
1. No validation in createCDATASection
createCDATASection: function (data) accepts any string and appends it directly.
- Lines 2216–2221 (0.9.8)
2. Unsafe CDATA serialization
Serializer prints CDATA sections as:
<![CDATA[ + node.data + ]]>
without handling ]]> in the data.
- Lines 2919–2920 (0.9.8)
Because CDATA content is emitted verbatim, an embedded ]]> closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML.
Proof of Concept — Fix A: createCDATASection now throws
On patched versions, passing ]]> directly to createCDATASection throws InvalidCharacterError instead of silently accepting the payload:
const { DOMImplementation } = require('./lib');
const doc = new DOMImplementation().createDocument(null, 'root', null);
try {
doc.createCDATASection('SAFE]]><injected attr="pwn"/>');
console.log('VULNERABLE — no error thrown');
} catch (e) {
console.log('FIXED — threw:', e.name); // InvalidCharacterError
}
Expected output on patched versions:
FIXED — threw: InvalidCharacterError
Proof of Concept — Fix B: mutation vector now safe
On patched versions, injecting ]]> via a mutation method (appendData, replaceData, .data =, .textContent =) no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text:
const { DOMImplementation, XMLSerializer } = require('./lib');
const { DOMParser } = require('./lib');
const doc = new DOMImplementation().createDocument(null, 'root', null);
// Start with safe data, then mutate to include the terminator
const cdata = doc.createCDATASection('safe');
doc.documentElement.appendChild(cdata);
cdata.appendData(']]><injected attr="pwn"/><more>TEXT</more><![CDATA[');
const out = new XMLSerializer().serializeToString(doc);
console.log('Serialized:', out);
const reparsed = new DOMParser().parseFromString(out, 'text/xml');
const injected = reparsed.getElementsByTagName('injected').length > 0;
console.log('Injected element found in reparsed doc:', injected);
// VULNERABLE: true | FIXED: false
Expected output on patched versions:
Serialized: <root><![CDATA[safe]]]]><![CDATA[><injected attr="pwn"/><more>TEXT</more><![CDATA[]]></root>
Injected element found in reparsed doc: false
Fix Applied
Both mitigations were implemented:
Option A — Strict/spec-aligned: reject ]]> in createCDATASection()
Document.createCDATASection(data) now throws InvalidCharacterError (per the WHATWG DOM spec) when data contains ]]>. This closes the direct entry point.
Code that previously passed a string containing ]]> to createCDATASection and relied on the silent/unsafe behaviour will now receive InvalidCharacterError. Use a mutation method such as appendData if you intentionally need ]]> in a CDATASection node's data (the serializer split in Option B will keep the output safe).
Option B — Defensive serialization: split the terminator during serialization
XMLSerializer now replaces every occurrence of ]]> in CDATA section data with the split sequence ]]]]><![CDATA[> before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how ]]> entered the node.
Update — 2026-04-xx (0.9.10 / 0.8.13)
splitCDATASections is deprecated
The CDATA split behavior introduced as Option B of this fix (replacing ]]> with]]]]><![CDATA[> during serialization) is deprecated as of 0.9.10 / 0.8.13.
This release introduces a requireWellFormed option on XMLSerializer.serializeToString(). When { requireWellFormed: true } is passed as the second argument, the serializer throws InvalidStateError if CDATA section data contains ]]> — this is the spec-aligned behavior (W3C DOM Parsing and Serialization, require well-formed flag) and the recommended migration path going forward.
The split behavior is now controlled by an explicit splitCDATASections option (default true, preserving the current behavior). The three serialization behaviors are:
| requireWellFormed | splitCDATASections | Behavior ||---|---|---|| false (default) | true (default) | Split ]]> → ]]]]><![CDATA[> (current behavior, deprecated) || true | — (ignored) | Throw InvalidStateError — spec-aligned, recommended |\ false | false | Emit verbatim — same as pre-0.9.9 behavior |
requireWellFormed: true takes precedence: the split path is unreachable when it is set.
Migration
Replace any reliance on the default split behavior with an explicit opt-in: ```js// Before (implicit split, deprecated): const xml = new XMLSerializer().serializeToString(doc);
// After (explicit guard, spec-aligned): const xml = new XMLSerializer().serializeToString(doc, { requireWellFormed: true }); // Throws InvalidStateError if any CDATASection contains ']]>' ```
Removal timeline
Both the splitCDATASections option and the underlying ]]> → ]]]]><![CDATA[> split mechanics will be removed in the next breaking (0.10.0) release. After removal, the only behaviors will be verbatim (default) and requireWellFormed: true (throws).
Removal is tracked in xmldom/xmldom#999.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34601"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T00:19:06Z",
"nvd_published_at": "2026-04-02T18:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`@xmldom/xmldom` allows attacker-controlled strings containing the CDATA terminator `]]\u003e` to be inserted into a `CDATASection` node. During serialization, `XMLSerializer` emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became **active XML markup** in the serialized output, enabling XML structure\ninjection and downstream business-logic manipulation.\n\nThe sequence `]]\u003e` is not allowed inside CDATA content and must be rejected or safely handled during serialization. ([MDN Web Docs](https://developer.mozilla.org/))\n\n### Attack surface\n\n`Document.createCDATASection(data)` is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate `]]\u003e` in mutation methods \u2014 only `createCDATASection` carries that guard. The following paths therefore also allow `]]\u003e` to enter a CDATASection node and reach the serializer:\n\n- `CharacterData.appendData()`\n- `CharacterData.replaceData()`\n- `CharacterData.insertData()`\n- Direct assignment to `.data`\n- Direct assignment to `.textContent`\n\n(Note: assigning to `.nodeValue` does **not** update `.data` in this implementation \u2014 the serializer reads `.data` directly \u2014 so `.nodeValue` is not an exploitable path.)\n\n### Parse path\n\nParsing XML that contains a CDATA section is **not** affected. The SAX parser\u0027s non-greedy `CDSect` regex stops at the first `]]\u003e`, so parsed CDATA data never contains the terminator.\n\n---\n\n## Impact\n\nIf an application uses `xmldom` to generate \"trusted\" XML documents that embed **untrusted user input** inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document.\n\nThis can lead to:\n\n- Integrity violation of generated XML documents.\n- Business-logic injection in downstream consumers (e.g., injecting `\u003capproved\u003etrue\u003c/approved\u003e`, `\u003crole\u003eadmin\u003c/role\u003e`, workflow flags, or other security-relevant elements).\n- Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear.\n\nThis issue does **not** require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup.\n\n---\n\n## Root Cause (with file + line numbers)\n\n**File:** `lib/dom.js`\n\n### 1. No validation in `createCDATASection`\n\n`createCDATASection: function (data)` accepts any string and appends it directly.\n\n- **Lines 2216\u20132221** (0.9.8)\n\n### 2. Unsafe CDATA serialization\n\nSerializer prints CDATA sections as:\n\n```\n\u003c![CDATA[ + node.data + ]]\u003e\n```\n\nwithout handling `]]\u003e` in the data.\n\n- **Lines 2919\u20132920** (0.9.8)\n\nBecause CDATA content is emitted verbatim, an embedded `]]\u003e` closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML.\n\n---\n\n## Proof of Concept \u2014 Fix A: `createCDATASection` now throws\n\nOn patched versions, passing `]]\u003e` directly to `createCDATASection` throws `InvalidCharacterError` instead of silently accepting the payload:\n\n```js\nconst { DOMImplementation } = require(\u0027./lib\u0027);\n\nconst doc = new DOMImplementation().createDocument(null, \u0027root\u0027, null);\ntry {\n doc.createCDATASection(\u0027SAFE]]\u003e\u003cinjected attr=\"pwn\"/\u003e\u0027);\n console.log(\u0027VULNERABLE \u2014 no error thrown\u0027);\n} catch (e) {\n console.log(\u0027FIXED \u2014 threw:\u0027, e.name); // InvalidCharacterError\n}\n```\n\nExpected output on patched versions:\n\n```\nFIXED \u2014 threw: InvalidCharacterError\n```\n\n---\n\n## Proof of Concept \u2014 Fix B: mutation vector now safe\n\nOn patched versions, injecting `]]\u003e` via a mutation method (`appendData`, `replaceData`, `.data =`, `.textContent =`) no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text:\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027./lib\u0027);\nconst { DOMParser } = require(\u0027./lib\u0027);\n\nconst doc = new DOMImplementation().createDocument(null, \u0027root\u0027, null);\n\n// Start with safe data, then mutate to include the terminator\nconst cdata = doc.createCDATASection(\u0027safe\u0027);\ndoc.documentElement.appendChild(cdata);\ncdata.appendData(\u0027]]\u003e\u003cinjected attr=\"pwn\"/\u003e\u003cmore\u003eTEXT\u003c/more\u003e\u003c![CDATA[\u0027);\n\nconst out = new XMLSerializer().serializeToString(doc);\nconsole.log(\u0027Serialized:\u0027, out);\n\nconst reparsed = new DOMParser().parseFromString(out, \u0027text/xml\u0027);\nconst injected = reparsed.getElementsByTagName(\u0027injected\u0027).length \u003e 0;\nconsole.log(\u0027Injected element found in reparsed doc:\u0027, injected);\n// VULNERABLE: true | FIXED: false\n```\n\nExpected output on patched versions:\n\n```\nSerialized: \u003croot\u003e\u003c![CDATA[safe]]]]\u003e\u003c![CDATA[\u003e\u003cinjected attr=\"pwn\"/\u003e\u003cmore\u003eTEXT\u003c/more\u003e\u003c![CDATA[]]\u003e\u003c/root\u003e\nInjected element found in reparsed doc: false\n```\n\n---\n\n## Fix Applied\n\nBoth mitigations were implemented:\n\n### Option A \u2014 Strict/spec-aligned: reject `]]\u003e` in `createCDATASection()`\n\n`Document.createCDATASection(data)` now throws `InvalidCharacterError` (per the [WHATWG DOM spec](https://dom.spec.whatwg.org/#dom-document-createcdatasection)) when `data` contains `]]\u003e`. This closes the direct entry point.\n\nCode that previously passed a string containing `]]\u003e` to `createCDATASection` and relied on the silent/unsafe behaviour will now receive `InvalidCharacterError`. Use a mutation method such as `appendData` if you intentionally need `]]\u003e` in a CDATASection node\u0027s data (the serializer split in Option B will keep the output safe).\n\n### Option B \u2014 Defensive serialization: split the terminator during serialization\n\n`XMLSerializer` now replaces every occurrence of `]]\u003e` in CDATA section data with the split sequence `]]]]\u003e\u003c![CDATA[\u003e` before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how `]]\u003e` entered the node.\n\n## Update \u2014 2026-04-xx (0.9.10 / 0.8.13)\n\n### `splitCDATASections` is deprecated\n\nThe CDATA split behavior introduced as Option B of this fix (replacing `]]\u003e` with`]]]]\u003e\u003c![CDATA[\u003e` during serialization) is **deprecated** as of 0.9.10 / 0.8.13.\n\nThis release introduces a `requireWellFormed` option on `XMLSerializer.serializeToString()`. When `{ requireWellFormed: true }` is passed as the second argument, the serializer throws `InvalidStateError` if CDATA section data contains `]]\u003e` \u2014 this is the spec-aligned behavior (W3C DOM Parsing and Serialization, `require well-formed` flag) and the recommended migration path going forward.\nThe split behavior is now controlled by an explicit `splitCDATASections` option (default `true`, preserving the current behavior). The three serialization behaviors are:\n| `requireWellFormed` | `splitCDATASections` | Behavior ||---|---|---|| `false` (default) | `true` (default) | Split `]]\u003e` \u2192 `]]]]\u003e\u003c![CDATA[\u003e` (current behavior, deprecated) || `true` | \u2014 (ignored) | Throw `InvalidStateError` \u2014 spec-aligned, recommended |\\ `false` | `false` | Emit verbatim \u2014 same as pre-0.9.9 behavior |\n\n`requireWellFormed: true` takes precedence: the split path is unreachable when it is set.\n\n### Migration\nReplace any reliance on the default split behavior with an explicit opt-in:\n```js// Before (implicit split, deprecated): const xml = new XMLSerializer().serializeToString(doc);\n\n// After (explicit guard, spec-aligned): const xml = new XMLSerializer().serializeToString(doc, { requireWellFormed: true }); // Throws InvalidStateError if any CDATASection contains \u0027]]\u003e\u0027 ```\n\n### Removal timeline\nBoth the `splitCDATASections` option and the underlying `]]\u003e` \u2192 `]]]]\u003e\u003c.",
"id": "GHSA-wh4c-j3r5-mjhp",
"modified": "2026-04-24T23:17:44Z",
"published": "2026-04-01T00:19:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-wh4c-j3r5-mjhp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34601"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/2b852e836ab86dbbd6cbaf0537f584dd0b5ac184"
},
{
"type": "PACKAGE",
"url": "https://github.com/xmldom/xmldom"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.8.12"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.9.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "xmldom: XML injection via unsafe CDATA serialization allows attacker-controlled markup insertion"
}
GHSA-WHJ6-8XVC-HMJM
Vulnerability from github – Published: 2022-05-24 22:29 – Updated: 2022-06-01 00:00A heap-based buffer overflow vulnerability exists in the XML Decompression EnumerationUncompressor::UncompressItem functionality of AT&T Labs’ Xmill 0.7. A specially crafted XMI file can lead to remote code execution. An attacker can provide a malicious file to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-21829"
],
"database_specific": {
"cwe_ids": [
"CWE-787",
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-13T19:15:00Z",
"severity": "CRITICAL"
},
"details": "A heap-based buffer overflow vulnerability exists in the XML Decompression EnumerationUncompressor::UncompressItem functionality of AT\u0026T Labs\u2019 Xmill 0.7. A specially crafted XMI file can lead to remote code execution. An attacker can provide a malicious file to trigger this vulnerability.",
"id": "GHSA-whj6-8xvc-hmjm",
"modified": "2022-06-01T00:00:24Z",
"published": "2022-05-24T22:29:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21829"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1292"
}
],
"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"
}
]
}
GHSA-X6WF-F3PX-WCQX
Vulnerability from github – Published: 2026-04-22 20:17 – Updated: 2026-05-08 20:10Summary
The package allows attacker-controlled processing instruction data to be serialized into XML without validating or neutralizing the PI-closing sequence ?>. As a result, an attacker can terminate the processing instruction early and inject arbitrary XML nodes into the serialized output.
Details
The issue is in the DOM construction and serialization flow for processing instruction nodes.
When createProcessingInstruction(target, data) is called, the supplied data string is stored directly on the node without validation. Later, when the document is serialized, the serializer writes PI nodes by concatenating <?, the target, a space, node.data, and ?> directly.
That behavior is unsafe because processing instructions are a syntax-sensitive context. The closing delimiter ?> terminates the PI. If attacker-controlled input contains ?>, the serializer does not preserve it as literal PI content. Instead, it emits output where the remainder of the payload is treated as live XML markup.
The same class of vulnerability was previously addressed for CDATA sections (GHSA-wh4c-j3r5-mjhp / CVE-2026-34601), where ]]> in CDATA data was handled by splitting. The serializer applies no equivalent protection to processing instruction data.
Affected code
lib/dom.js — createProcessingInstruction (lines 2240–2246):
createProcessingInstruction: function (target, data) {
var node = new ProcessingInstruction(PDC);
node.ownerDocument = this;
node.childNodes = new NodeList();
node.nodeName = node.target = target;
node.nodeValue = node.data = data;
return node;
},
No validation is performed on data. Any string including ?> is stored as-is.
lib/dom.js — serializer PI case (line 2966):
case PROCESSING_INSTRUCTION_NODE:
return buf.push('<?', node.target, ' ', node.data, '?>');
node.data is emitted verbatim. If it contains ?>, that sequence terminates the PI in the output
stream and the remainder appears as active XML markup.
Contrast — CDATA (line 2945, patched):
case CDATA_SECTION_NODE:
return buf.push(g.CDATA_START, node.data.replace(/]]>/g, ']]]]><![CDATA[>'), g.CDATA_END);
PoC
Minimal (from @tlsbollei report, 2026-04-01)
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(
doc.createProcessingInstruction('a', '?><z/><?q ')
);
console.log(new XMLSerializer().serializeToString(doc));
// <r><?a ?><z/><?q ?></r>
// ^^^^ injected <z/> element is active markup
With re-parse verification (from @tlsbollei report)
const assert = require('assert');
const { DOMParser, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMParser().parseFromString('<r/>', 'application/xml');
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));
const xml = new XMLSerializer().serializeToString(doc);
assert.strictEqual(new DOMParser().parseFromString(xml, 'application/xml')
.getElementsByTagName('z').length, 1); // passes — z is a real element
Impact
An application that uses the package to build XML from untrusted input can be made to emit attacker-controlled elements outside the intended PI boundary. That allows the attacker to alter the meaning and structure of generated XML documents.
In practice, this can affect any workflow that generates XML and then stores it, forwards it, signs it, or hands it to another parser. Realistic targets include XML-based configuration, policy documents, and message formats where downstream consumers trust the serialized structure.
As noted by @tlsbollei: this is the same delimiter-driven XML injection bug class previously addressed by GHSA-wh4c-j3r5-mjhp for createCDATASection(). Fixing CDATA while leaving PI creation and PI serialization unguarded leaves the same standards-constrained issue open for another node type.
Disclosure
This vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via xmldom/xmldom#987, which was subsequently closed without being merged.
Fix Applied
⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain vulnerable unless
{ requireWellFormed: true }is explicitly passed. Applications that pass untrusted data tocreateProcessingInstruction()or mutate PI nodes with untrusted input (via.data =orCharacterDatamutation methods) should audit allserializeToString()call sites and add the option.
XMLSerializer.serializeToString() now accepts an options object as a second argument. When { requireWellFormed: true } is passed, the serializer throws InvalidStateError before emitting any ProcessingInstruction node whose .data contains ?>. This check applies regardless of how ?> entered the node — whether via createProcessingInstruction directly or a subsequent mutation (.data =, CharacterData methods).
On @xmldom/xmldom ≥ 0.9.10, the serializer additionally applies the full W3C DOM Parsing §3.2.1.7 checks when requireWellFormed: true:
- Target check: throws
InvalidStateErrorif the PI target contains a:character or is an ASCII case-insensitive match for"xml". - Data Char check: throws
InvalidStateErrorif the PI data contains characters outside the XML Char production. - Data sequence check: throws
InvalidStateErrorif the PI data contains?>.
On @xmldom/xmldom ≥ 0.8.13 (LTS), only the ?> data check (check 3) is applied. The target and XML Char checks are not included in the LTS fix.
PoC — fixed path
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));
// Default (unchanged): verbatim — injection present
const unsafe = new XMLSerializer().serializeToString(doc);
console.log(unsafe);
// <r><?a ?><z/><?q ?></r>
// Opt-in guard: throws InvalidStateError before serializing
try {
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
console.log(e.name, e.message);
// InvalidStateError: The ProcessingInstruction data contains "?>"
}
The guard catches ?> regardless of when it was introduced:
// Post-creation mutation: also caught at serialization time
const pi = doc.createProcessingInstruction('target', 'safe data');
doc.documentElement.appendChild(pi);
pi.data = 'safe?><injected/>';
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
// InvalidStateError: The ProcessingInstruction data contains "?>"
Why the default stays verbatim
The W3C DOM Parsing and Serialization spec §3.2.1.3 defines a require well-formed flag whose default value is false. With the flag unset, the spec explicitly permits serializing PI data verbatim. This matches browser behavior: Chrome, Firefox, and Safari all emit ?> in PI data verbatim by default without error.
Unconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in requireWellFormed: true flag allows applications that require injection safety to enable strict mode without breaking existing code.
Residual limitation
createProcessingInstruction(target, data) does not validate data at creation time. The WHATWG DOM spec (§4.5 step 2) mandates an InvalidCharacterError when data contains ?>; enforcing this check unconditionally at creation time is a breaking change and is deferred to a future breaking release.
When the default serialization path is used (without requireWellFormed: true), PI data containing ?> is still emitted verbatim. Applications that do not pass requireWellFormed: true remain exposed.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41675"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T20:17:58Z",
"nvd_published_at": "2026-05-07T04:16:33Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe package allows attacker-controlled processing instruction data to be serialized into XML without validating or neutralizing the PI-closing sequence `?\u003e`. As a result, an attacker can terminate the processing instruction early and inject arbitrary XML nodes into the serialized output.\n\n---\n\n## Details\n\nThe issue is in the DOM construction and serialization flow for processing instruction nodes.\n\nWhen `createProcessingInstruction(target, data)` is called, the supplied `data` string is stored directly on the node without validation. Later, when the document is serialized, the serializer writes PI nodes by concatenating `\u003c?`, the target, a space, `node.data`, and `?\u003e` directly.\n\nThat behavior is unsafe because processing instructions are a syntax-sensitive context. The closing delimiter `?\u003e` terminates the PI. If attacker-controlled input contains `?\u003e`, the serializer does not preserve it as literal PI content. Instead, it emits output where the remainder of the payload is treated as live XML markup.\n\nThe same class of vulnerability was previously addressed for CDATA sections (GHSA-wh4c-j3r5-mjhp / CVE-2026-34601), where `]]\u003e` in CDATA data was handled by splitting. The serializer applies no equivalent protection to processing instruction data.\n\n---\n\n## Affected code\n\n**`lib/dom.js` \u2014 `createProcessingInstruction` (lines 2240\u20132246):**\n\n```js\ncreateProcessingInstruction: function (target, data) {\n var node = new ProcessingInstruction(PDC);\n node.ownerDocument = this;\n node.childNodes = new NodeList();\n node.nodeName = node.target = target;\n node.nodeValue = node.data = data;\n return node;\n},\n```\n\nNo validation is performed on `data`. Any string including `?\u003e` is stored as-is.\n\n**`lib/dom.js` \u2014 serializer PI case (line 2966):**\n\n```js\ncase PROCESSING_INSTRUCTION_NODE:\n return buf.push(\u0027\u003c?\u0027, node.target, \u0027 \u0027, node.data, \u0027?\u003e\u0027);\n```\n\n`node.data` is emitted verbatim. If it contains `?\u003e`, that sequence terminates the PI in the output\nstream and the remainder appears as active XML markup.\n\n**Contrast \u2014 CDATA (line 2945, patched):**\n\n```js\ncase CDATA_SECTION_NODE:\n return buf.push(g.CDATA_START, node.data.replace(/]]\u003e/g, \u0027]]]]\u003e\u003c, which was subsequently closed\nwithout being merged.\n\n---\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 pass\n\u003e untrusted data to `createProcessingInstruction()` or mutate PI nodes with untrusted input\n\u003e (via `.data =` or `CharacterData` mutation methods) should audit all `serializeToString()`\n\u003e call sites and add the option.\n\n`XMLSerializer.serializeToString()` now accepts an options object as a second argument. When `{ requireWellFormed: true }` is passed, the serializer throws `InvalidStateError` before emitting any ProcessingInstruction node whose `.data` contains `?\u003e`. This check applies regardless of how `?\u003e` entered the node \u2014 whether via `createProcessingInstruction` directly or a subsequent mutation (`.data =`, `CharacterData` methods).\n\nOn `@xmldom/xmldom` \u2265 0.9.10, the serializer additionally applies the full W3C DOM Parsing \u00a73.2.1.7 checks when `requireWellFormed: true`:\n\n1. **Target check**: throws `InvalidStateError` if the PI target contains a `:` character or is an ASCII case-insensitive match for `\"xml\"`.\n2. **Data Char check**: throws `InvalidStateError` if the PI data contains characters outside the XML Char production.\n3. **Data sequence check**: throws `InvalidStateError` if the PI data contains `?\u003e`.\n\nOn `@xmldom/xmldom` \u2265 0.8.13 (LTS), only the `?\u003e` data check (check 3) is applied. The target and XML Char checks are not included in the LTS fix.\n\n### PoC \u2014 fixed path\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst doc = new DOMImplementation().createDocument(null, \u0027r\u0027, null);\ndoc.documentElement.appendChild(doc.createProcessingInstruction(\u0027a\u0027, \u0027?\u003e\u003cz/\u003e\u003c?q \u0027));\n\n// Default (unchanged): verbatim \u2014 injection present\nconst unsafe = new XMLSerializer().serializeToString(doc);\nconsole.log(unsafe);\n// \u003cr\u003e\u003c?a ?\u003e\u003cz/\u003e\u003c?q ?\u003e\u003c/r\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 ProcessingInstruction data contains \"?\u003e\"\n}\n```\n\nThe guard catches `?\u003e` regardless of when it was introduced:\n\n```js\n// Post-creation mutation: also caught at serialization time\nconst pi = doc.createProcessingInstruction(\u0027target\u0027, \u0027safe data\u0027);\ndoc.documentElement.appendChild(pi);\npi.data = \u0027safe?\u003e\u003cinjected/\u003e\u0027;\nnew XMLSerializer().serializeToString(doc, { requireWellFormed: true });\n// InvalidStateError: The ProcessingInstruction data contains \"?\u003e\"\n```\n\n### Why the default stays verbatim\n\nThe W3C DOM Parsing and Serialization spec \u00a73.2.1.3 defines a `require well-formed` flag whose **default value is `false`**. With the flag unset, the spec explicitly permits serializing PI data verbatim. This matches browser behavior: Chrome, Firefox, and Safari all emit `?\u003e` in PI data verbatim by default without error.\n\nUnconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in `requireWellFormed: true` flag allows applications that require injection safety to enable strict mode without breaking existing code.\n\n### Residual limitation\n\n`createProcessingInstruction(target, data)` does not validate `data` at creation time. The WHATWG DOM spec (\u00a74.5 step 2) mandates an `InvalidCharacterError` when `data` contains `?\u003e`; enforcing this check unconditionally at creation time is a breaking change and is deferred to a future breaking release.\n\nWhen the default serialization path is used (without `requireWellFormed: true`), PI data containing `?\u003e` is still emitted verbatim. Applications that do not pass `requireWellFormed: true` remain exposed.",
"id": "GHSA-x6wf-f3px-wcqx",
"modified": "2026-05-08T20:10:13Z",
"published": "2026-04-22T20:17:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-x6wf-f3px-wcqx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41675"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/7207a4b0e0bcc228868075ed991665ef9f73b1c2"
},
{
"type": "PACKAGE",
"url": "https://github.com/xmldom/xmldom"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.8.13"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.9.10"
}
],
"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 has XML node injection through unvalidated processing instruction serialization"
}
GHSA-XCRG-29H7-H4CJ
Vulnerability from github – Published: 2019-11-20 01:38 – Updated: 2025-03-06 18:08securityScan() in PHPOffice PhpSpreadsheet through 1.5.0 allows a bypass of protection mechanisms for XXE via UTF-7 encoding in a .xlsx file
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpoffice/phpspreadsheet"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpoffice/phpexcel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-19277"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2019-11-19T03:40:52Z",
"nvd_published_at": "2018-11-14T11:29:00Z",
"severity": "HIGH"
},
"details": "securityScan() in PHPOffice PhpSpreadsheet through 1.5.0 allows a bypass of protection mechanisms for XXE via UTF-7 encoding in a .xlsx file",
"id": "GHSA-xcrg-29h7-h4cj",
"modified": "2025-03-06T18:08:03Z",
"published": "2019-11-20T01:38:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19277"
},
{
"type": "WEB",
"url": "https://github.com/MewesK/TwigSpreadsheetBundle/issues/18"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PhpSpreadsheet/issues/771"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PhpSpreadsheet/pull/780"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PHPExcel/commit/2b601574975acfb9d4378a788ed5f2b747958095"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/0f8f071e24ee8b114d894ac172f77dc250e5bfa4"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/phpoffice/phpspreadsheet/CVE-2018-19277.yaml"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PHPExcel/commits/1.8.2"
},
{
"type": "PACKAGE",
"url": "https://github.com/PHPOffice/PhpSpreadsheet"
},
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/1.5.1"
},
{
"type": "WEB",
"url": "https://www.bishopfox.com/news/2018/11/phpoffice-versions"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2021-043"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XXE in PHPSpreadsheet due to encoding issue"
}
GHSA-XP76-33M9-43WW
Vulnerability from github – Published: 2025-09-09 12:30 – Updated: 2025-11-05 00:31XML Injection RCE by parse http sitemap xml response vulnerability in Apache HertzBeat.
The attacker needs to have an authenticated account with access, and add monitor parsed by xml, returned special content can trigger the XML parsing vulnerability.
This issue affects Apache HertzBeat (incubating): before 1.7.0.
Users are recommended to upgrade to version 1.7.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2025-24404"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T10:15:33Z",
"severity": "HIGH"
},
"details": "XML Injection RCE by parse http sitemap xml response vulnerability in Apache HertzBeat.\n\n\n\n\n\n\n\n\n\n\n\n\nThe attacker needs to have an authenticated account with access, and add monitor parsed by xml, returned special content can trigger the XML parsing vulnerability.\n\nThis issue affects Apache HertzBeat (incubating): before 1.7.0.\n\nUsers are recommended to upgrade to version 1.7.0, which fixes the issue.",
"id": "GHSA-xp76-33m9-43ww",
"modified": "2025-11-05T00:31:26Z",
"published": "2025-09-09T12:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24404"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/4ydy3tqbpwmhl79mcj3pxwqz62nggrfd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/09/06/4"
}
],
"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"
}
]
}
GHSA-XQVG-MHW9-7644
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12In ForgeRock Access Management (AM) before 7.0.2, the SAML2 implementation allows XML injection, potentially enabling a fraudulent SAML 2.0 assertion.
{
"affected": [],
"aliases": [
"CVE-2021-37154"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-25T21:15:00Z",
"severity": "CRITICAL"
},
"details": "In ForgeRock Access Management (AM) before 7.0.2, the SAML2 implementation allows XML injection, potentially enabling a fraudulent SAML 2.0 assertion.",
"id": "GHSA-xqvg-mhw9-7644",
"modified": "2022-05-24T19:12:07Z",
"published": "2022-05-24T19:12:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37154"
},
{
"type": "WEB",
"url": "https://backstage.forgerock.com/knowledge/kb/article/a55763454"
},
{
"type": "WEB",
"url": "https://www.forgerock.com/platform/access-management"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XVPX-6HH8-7H72
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2025-11-06 23:37Magento 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 in the 'City' field. An unauthenticated attacker 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-36020"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T23:37:40Z",
"nvd_published_at": "2021-09-01T15:15:00Z",
"severity": "HIGH"
},
"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 in the \u0027City\u0027 field. An unauthenticated attacker can trigger a specially crafted script to achieve remote code execution.",
"id": "GHSA-xvpx-6hh8-7h72",
"modified": "2025-11-06T23:37:40Z",
"published": "2022-05-24T19:12:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36020"
},
{
"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": [],
"summary": "Magento XML Injection vulnerability in the \u0027City\u0027 field"
}
GHSA-XXX9-3XCR-GJJ3
Vulnerability from github – Published: 2022-04-11 21:30 – Updated: 2022-04-11 21:30Summary
Nokogiri v1.13.4 updates the vendored xerces:xercesImpl from 2.12.0 to 2.12.2, which addresses CVE-2022-23437. That CVE is scored as CVSS 6.5 "Medium" on the NVD record.
Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4.
Mitigation
Upgrade to Nokogiri >= v1.13.4.
Impact
CVE-2022-23437 in xerces-J
- Severity: Medium
- Type: CWE-91 XML Injection (aka Blind XPath Injection)
- Description: There's a vulnerability within the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This causes, the XercesJ XML parser to wait in an infinite loop, which may sometimes consume system resources for prolonged duration. This vulnerability is present within XercesJ version 2.12.1 and the previous versions.
- See also: https://github.com/advisories/GHSA-h65f-jvqw-m9fj
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "nokogiri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-11T21:30:00Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nNokogiri v1.13.4 updates the vendored `xerces:xercesImpl` from 2.12.0 to 2.12.2, which addresses [CVE-2022-23437](https://nvd.nist.gov/vuln/detail/CVE-2022-23437). That CVE is scored as CVSS 6.5 \"Medium\" on the NVD record.\n\nPlease note that this advisory only applies to the **JRuby** implementation of Nokogiri `\u003c 1.13.4`.\n\n## Mitigation\n\nUpgrade to Nokogiri `\u003e= v1.13.4`.\n\n## Impact\n\n### [CVE-2022-23437](https://nvd.nist.gov/vuln/detail/CVE-2022-23437) in xerces-J\n\n- **Severity**: Medium\n- **Type**: [CWE-91](https://cwe.mitre.org/data/definitions/91.html) XML Injection (aka Blind XPath Injection)\n- **Description**: There\u0027s a vulnerability within the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This causes, the XercesJ XML parser to wait in an infinite loop, which may sometimes consume system resources for prolonged duration. This vulnerability is present within XercesJ version 2.12.1 and the previous versions.\n- **See also**: https://github.com/advisories/GHSA-h65f-jvqw-m9fj\n\n",
"id": "GHSA-xxx9-3xcr-gjj3",
"modified": "2022-04-11T21:30:00Z",
"published": "2022-04-11T21:30:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-xxx9-3xcr-gjj3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23437"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-h65f-jvqw-m9fj"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparklemotion/nokogiri"
},
{
"type": "WEB",
"url": "https://github.com/sparklemotion/nokogiri/releases/tag/v1.13.4"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/ruby-security-ann/c/vX7qSjsvWis/m/TJWN4oOKBwAJ?utm_medium=email\u0026utm_source=footer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "XML Injection in Xerces Java affects Nokogiri"
}
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.