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-C2QG-83F7-XWCM
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14Injection attack caused the denial of service vulnerability in NetIQ Access Manager prior to 5.0.1 and 4.5.4
{
"affected": [],
"aliases": [
"CVE-2021-22524"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-13T12:15:00Z",
"severity": "MODERATE"
},
"details": "Injection attack caused the denial of service vulnerability in NetIQ Access Manager prior to 5.0.1 and 4.5.4",
"id": "GHSA-c2qg-83f7-xwcm",
"modified": "2022-05-24T19:14:21Z",
"published": "2022-05-24T19:14:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22524"
},
{
"type": "WEB",
"url": "https://support.microfocus.com/kb/doc.php?id=7025256"
},
{
"type": "WEB",
"url": "https://www.microfocus.com/documentation/access-manager/5.0/accessmanager501-release-notes/accessmanager501-release-notes.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C7Q8-3CH8-VQPV
Vulnerability from github – Published: 2026-09-08 21:03 – Updated: 2026-09-08 21:03Summary
Document.createProcessingInstruction() in @xmldom/xmldom performs no validation on the target parameter. The requireWellFormed: true serializer option validates only for : in the target and a case-insensitive xml prefix, but does not check for > characters. A > in the target breaks the processing instruction boundary (<?...?>), allowing injection of arbitrary content into the serialized XML output.
Details
Document.createProcessingInstruction(target, data) at lib/dom.js around line 2413 accepts any string as the target parameter and stores it on the PI node without validation.
During serialization, the requireWellFormed code path (around line 3286) performs two checks on PI targets:
- Rejects targets containing
:(namespace prefix check) - Rejects targets matching
xmlcase-insensitively (reserved prefix)
However, it does NOT validate that the target conforms to the XML Name production, and critically does NOT check for > characters. Since processing instructions are serialized as <?target data?>, a > in the target prematurely closes the PI, causing the remaining content to be interpreted as document content by any downstream XML parser.
Root Cause
createProcessingInstruction()performs no validation ontarget- The serializer's
requireWellFormedcheck is incomplete -- it only checks for:andxml, missing characters that break PI syntax (>,?, whitespace) - The serializer emits the target verbatim:
<?${target} ${data}?>
Proof of Concept
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// PI target containing > breaks the PI boundary
const pi = doc.createProcessingInstruction('a>', 'data');
doc.documentElement.appendChild(pi);
const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// Output: <root><?a> data?></root>
//
// The > in the target closes the PI prematurely.
// A downstream XML parser sees:
// - Processing instruction: <?a?> (target "a", no data)
// - Text content: " data?>"
//
// requireWellFormed: true did NOT prevent the injection.
Injecting elements via PI target
const pi2 = doc.createProcessingInstruction(
'a?><script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script><?b',
''
);
doc.documentElement.appendChild(pi2);
const output2 = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output2);
// Output includes:
// <?a?><script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script><?b ?>
//
// The injected <script> element is valid XHTML that a browser would execute.
Impact
Applications that create processing instructions with user-controlled target strings and serialize the result are vulnerable to XML injection. This enables:
- XML structure injection: Breaking the PI boundary to inject arbitrary elements, text, or additional processing instructions into the output
- XSS via XHTML: If the serialized output is served as XHTML or processed by a browser-based XML parser, injected script elements will execute
- XXE chain: Injected DOCTYPE declarations or entity references could trigger XXE in downstream XML parsers that consume the output
- requireWellFormed bypass: The existing well-formedness checks are incomplete and provide a false sense of security
Fix Applied
Under requireWellFormed, the serializer validates a processing-instruction target as an XML NCName (a Name with no colon) and rejects a case-insensitive xml, throwing InvalidStateError when the target is ill-formed — so a >, ?, or whitespace in the target is now refused.\
On 0.9.12 this replaces an earlier check that already rejected a colon or xml, so the no-colon rule is preserved.\
0.8.15 had no processing-instruction target check at all, so the whole target validation is new there.\
Non-breaking and opt-in. See the XML Name production.
⚠ 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.
Proof of Concept - fixed path
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// PI target containing > breaks the PI boundary
const pi = doc.createProcessingInstruction('a>', 'data');
doc.documentElement.appendChild(pi);
// Default path: emits the ill-formed target verbatim.
console.log(serializer.serializeToString(doc));
// Output: <root><?a> data?></root>
// Opt-in path: the target check now rejects the break-out character.
try {
serializer.serializeToString(doc, { requireWellFormed: true });
} catch (e) {
console.log(e.name); // InvalidStateError
}
Why the default stays verbatim
W3C DOM Parsing's require-well-formed flag defaults to false, and the browser XMLSerializer emits the target verbatim in that default mode. Unconditionally throwing on an ill-formed PI target would diverge from that platform behavior and would be an unjustified breaking change, so the stricter validation is gated behind { requireWellFormed: true }. (See the W3C XML Name production and XML Processing Instructions.)
Residual limitation
The default serialization path still emits the ill-formed target verbatim -- only the opt-in requireWellFormed path is protected. Creation-time validation of the target in createProcessingInstruction() is breaking and is deferred to the next breaking release, tracked at xmldom/xmldom#1073.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.14"
},
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.0"
},
{
"fixed": "0.8.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.11"
},
"package": {
"ecosystem": "npm",
"name": "@xmldom/xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "xmldom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-83616"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T21:03:28Z",
"nvd_published_at": "2026-09-01T15:17:40Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Document.createProcessingInstruction()` in `@xmldom/xmldom` performs no validation on the `target` parameter. The `requireWellFormed: true` serializer option validates only for `:` in the target and a case-insensitive `xml` prefix, but does not check for `\u003e` characters. A `\u003e` in the target breaks the processing instruction boundary (`\u003c?...?\u003e`), allowing injection of arbitrary content into the serialized XML output.\n\n## Details\n\n`Document.createProcessingInstruction(target, data)` at `lib/dom.js` around line 2413 accepts any string as the `target` parameter and stores it on the PI node without validation.\n\nDuring serialization, the `requireWellFormed` code path (around line 3286) performs two checks on PI targets:\n\n1. Rejects targets containing `:` (namespace prefix check)\n2. Rejects targets matching `xml` case-insensitively (reserved prefix)\n\nHowever, it does NOT validate that the target conforms to the XML Name production, and critically does NOT check for `\u003e` characters. Since processing instructions are serialized as `\u003c?target data?\u003e`, a `\u003e` in the target prematurely closes the PI, causing the remaining content to be interpreted as document content by any downstream XML parser.\n\n### Root Cause\n\n1. `createProcessingInstruction()` performs no validation on `target`\n2. The serializer\u0027s `requireWellFormed` check is incomplete -- it only checks for `:` and `xml`, missing characters that break PI syntax (`\u003e`, `?`, whitespace)\n3. The serializer emits the target verbatim: `\u003c?${target} ${data}?\u003e`\n\n## Proof of Concept\n\n```javascript\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// PI target containing \u003e breaks the PI boundary\nconst pi = doc.createProcessingInstruction(\u0027a\u003e\u0027, \u0027data\u0027);\ndoc.documentElement.appendChild(pi);\n\nconst output = serializer.serializeToString(doc, { requireWellFormed: true });\nconsole.log(output);\n// Output: \u003croot\u003e\u003c?a\u003e data?\u003e\u003c/root\u003e\n//\n// The \u003e in the target closes the PI prematurely.\n// A downstream XML parser sees:\n// - Processing instruction: \u003c?a?\u003e (target \"a\", no data)\n// - Text content: \" data?\u003e\"\n//\n// requireWellFormed: true did NOT prevent the injection.\n```\n\n### Injecting elements via PI target\n\n```javascript\nconst pi2 = doc.createProcessingInstruction(\n \u0027a?\u003e\u003cscript xmlns=\"http://www.w3.org/1999/xhtml\"\u003ealert(1)\u003c/script\u003e\u003c?b\u0027,\n \u0027\u0027\n);\ndoc.documentElement.appendChild(pi2);\n\nconst output2 = serializer.serializeToString(doc, { requireWellFormed: true });\nconsole.log(output2);\n// Output includes:\n// \u003c?a?\u003e\u003cscript xmlns=\"http://www.w3.org/1999/xhtml\"\u003ealert(1)\u003c/script\u003e\u003c?b ?\u003e\n//\n// The injected \u003cscript\u003e element is valid XHTML that a browser would execute.\n```\n\n## Impact\n\nApplications that create processing instructions with user-controlled target strings and serialize the result are vulnerable to XML injection. This enables:\n\n- **XML structure injection**: Breaking the PI boundary to inject arbitrary elements, text, or additional processing instructions into the output\n- **XSS via XHTML**: If the serialized output is served as XHTML or processed by a browser-based XML parser, injected script elements will execute\n- **XXE chain**: Injected DOCTYPE declarations or entity references could trigger XXE in downstream XML parsers that consume the output\n- **requireWellFormed bypass**: The existing well-formedness checks are incomplete and provide a false sense of security\n\n## Fix Applied\n\nUnder `requireWellFormed`, the serializer validates a processing-instruction target as an XML `NCName` (a `Name` with no colon) and rejects a case-insensitive `xml`, throwing `InvalidStateError` when the target is ill-formed \u2014 so a `\u003e`, `?`, or whitespace in the target is now refused.\\\nOn 0.9.12 this replaces an earlier check that already rejected a colon or `xml`, so the no-colon rule is preserved.\\\n0.8.15 had no processing-instruction target check at all, so the whole target validation is new there.\\\nNon-breaking and opt-in. See the [XML `Name` production](https://www.w3.org/TR/xml/#NT-Name).\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\n### Proof of Concept - fixed path\n\n```javascript\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// PI target containing \u003e breaks the PI boundary\nconst pi = doc.createProcessingInstruction(\u0027a\u003e\u0027, \u0027data\u0027);\ndoc.documentElement.appendChild(pi);\n\n// Default path: emits the ill-formed target verbatim.\nconsole.log(serializer.serializeToString(doc));\n// Output: \u003croot\u003e\u003c?a\u003e data?\u003e\u003c/root\u003e\n\n// Opt-in path: the target check now rejects the break-out character.\ntry {\n serializer.serializeToString(doc, { requireWellFormed: true });\n} catch (e) {\n console.log(e.name); // InvalidStateError\n}\n```\n\n### Why the default stays verbatim\n\nW3C DOM Parsing\u0027s require-well-formed flag defaults to false, and the browser `XMLSerializer` emits the target verbatim in that default mode. Unconditionally throwing on an ill-formed PI target would diverge from that platform behavior and would be an unjustified breaking change, so the stricter validation is gated behind `{ requireWellFormed: true }`. (See the [W3C XML Name production](https://www.w3.org/TR/xml/#NT-Name) and [XML Processing Instructions](https://www.w3.org/TR/xml/#sec-pi).)\n\n### Residual limitation\n\nThe default serialization path still emits the ill-formed target verbatim -- only the opt-in `requireWellFormed` path is protected. Creation-time validation of the `target` in `createProcessingInstruction()` is breaking and is deferred to the next breaking release, tracked at [xmldom/xmldom#1073](https://github.com/xmldom/xmldom/issues/1073).",
"id": "GHSA-c7q8-3ch8-vqpv",
"modified": "2026-09-08T21:03:28Z",
"published": "2026-09-08T21:03:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-c7q8-3ch8-vqpv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83616"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/pull/1071"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/pull/1072"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/1cde3e31a07c41c87cfd368d6946aa477f16b4f9"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/3b694872bcb5c7e3cbadba961a4be2488750ce5b"
},
{
"type": "PACKAGE",
"url": "https://github.com/xmldom/xmldom"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.8.15"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.9.12"
}
],
"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: Processing Instruction Target Injection Bypasses requireWellFormed"
}
GHSA-C94C-G2HM-XG4P
Vulnerability from github – Published: 2024-03-20 15:32 – Updated: 2024-03-20 15:32A vulnerability, which was classified as problematic, was found in Netentsec NS-ASG Application Security Gateway 6.3. Affected is an unknown function of the file /nac/naccheck.php. The manipulation of the argument username leads to improper neutralization of data within xpath expressions. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-257286 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-2648"
],
"database_specific": {
"cwe_ids": [
"CWE-643",
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-19T23:15:10Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, was found in Netentsec NS-ASG Application Security Gateway 6.3. Affected is an unknown function of the file /nac/naccheck.php. The manipulation of the argument username leads to improper neutralization of data within xpath expressions. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-257286 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-c94c-g2hm-xg4p",
"modified": "2024-03-20T15:32:25Z",
"published": "2024-03-20T15:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2648"
},
{
"type": "WEB",
"url": "https://github.com/flyyue2001/cve/blob/main/NS-ASG-sql-naccheck.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.257286"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.257286"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CJ7W-PM77-HVG6
Vulnerability from github – Published: 2022-08-17 00:00 – Updated: 2024-01-11 19:09Adobe Commerce versions 2.4.3-p2 (and earlier), 2.3.7-p3 (and earlier) and 2.4.4 (and earlier) are affected by an XML Injection vulnerability in the Widgets Module. An attacker with admin privileges can trigger a specially crafted script to achieve remote code execution. Exploitation of this issue does not require user interaction.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.7-p4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.4"
},
{
"fixed": "2.4.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3-p3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-34253"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-11T19:09:38Z",
"nvd_published_at": "2022-08-16T21:15:00Z",
"severity": "CRITICAL"
},
"details": "Adobe Commerce versions 2.4.3-p2 (and earlier), 2.3.7-p3 (and earlier) and 2.4.4 (and earlier) are affected by an XML Injection vulnerability in the Widgets Module. An attacker with admin privileges can trigger a specially crafted script to achieve remote code execution. Exploitation of this issue does not require user interaction.",
"id": "GHSA-cj7w-pm77-hvg6",
"modified": "2024-01-11T19:09:38Z",
"published": "2022-08-17T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34253"
},
{
"type": "WEB",
"url": "https://github.com/magento/magento2/commit/246d524b7586af2245092008e0d92b8d6fdd8523"
},
{
"type": "WEB",
"url": "https://github.com/magento/magento2/commit/5548bc64b5bc904346c0af9193a7fbb5274b4efa"
},
{
"type": "WEB",
"url": "https://github.com/magento/magento2/commit/5f07eba878296a37bd5c3a2baecad48948547594"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb22-38.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Magento XML Injection vulnerability in the Widgets Module"
}
GHSA-CJQ5-2J3X-JVM9
Vulnerability from github – Published: 2023-08-23 21:30 – Updated: 2024-04-04 07:09In OpenMNS Horizon 31.0.8 and versions earlier than 32.0.2, the file editor which is accessible to any user with ROLE_FILESYSTEM_EDITOR privileges is vulnerable to XXE injection attacks. The solution is to upgrade to Meridian 2023.1.5 or Horizon 32.0.2 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet. OpenNMS thanks Erik Wynter for reporting this issue.
{
"affected": [],
"aliases": [
"CVE-2023-40612"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-23T19:15:08Z",
"severity": "HIGH"
},
"details": "In OpenMNS Horizon 31.0.8 and versions earlier than 32.0.2, the file editor which is accessible to any user with ROLE_FILESYSTEM_EDITOR privileges is vulnerable to XXE injection attacks. The solution is to upgrade to Meridian 2023.1.5 or Horizon 32.0.2 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization\u0027s private networks and should not be directly accessible from the Internet. OpenNMS thanks Erik Wynter for reporting this issue.",
"id": "GHSA-cjq5-2j3x-jvm9",
"modified": "2024-04-04T07:09:58Z",
"published": "2023-08-23T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40612"
},
{
"type": "WEB",
"url": "https://github.com/OpenNMS/opennms/pull/6288"
},
{
"type": "WEB",
"url": "https://docs.opennms.com/meridian/2023/releasenotes/changelog.html#releasenotes-changelog-Meridian-2023.1.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-CP3V-75FH-G783
Vulnerability from github – Published: 2023-10-14 15:30 – Updated: 2024-04-04 08:38IBM Security Directory Server 6.4.0 is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 228505.
{
"affected": [],
"aliases": [
"CVE-2022-32755"
],
"database_specific": {
"cwe_ids": [
"CWE-611",
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-14T15:15:09Z",
"severity": "CRITICAL"
},
"details": "IBM Security Directory Server 6.4.0 is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 228505.",
"id": "GHSA-cp3v-75fh-g783",
"modified": "2024-04-04T08:38:39Z",
"published": "2023-10-14T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32755"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/228505"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7047428"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2MM-M48V-8HRP
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2022-05-24 16:47An issue was discovered on D-Link DIR-818LW devices from 2.05.B03 to 2.06B01 BETA. There is a command injection in HNAP1 SetWanSettings via an XML injection of the value of the Gateway key.
{
"affected": [],
"aliases": [
"CVE-2019-12787"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-10T18:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on D-Link DIR-818LW devices from 2.05.B03 to 2.06B01 BETA. There is a command injection in HNAP1 SetWanSettings via an XML injection of the value of the Gateway key.",
"id": "GHSA-f2mm-m48v-8hrp",
"modified": "2022-05-24T16:47:41Z",
"published": "2022-05-24T16:47:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12787"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/blob/master/iot/dlink/dir818-2-protected.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F6WW-3GGP-FR8H
Vulnerability from github – Published: 2026-04-22 20:19 – Updated: 2026-05-08 20:10Summary
The package serializes DocumentType node fields (internalSubset, publicId, systemId) verbatim
without any escaping or validation. When these fields are set programmatically to attacker-controlled
strings, XMLSerializer.serializeToString can produce output where the DOCTYPE declaration is
terminated early and arbitrary markup appears outside it.
Details
DOMImplementation.createDocumentType(qualifiedName, publicId, systemId, internalSubset) validates
only qualifiedName against the XML QName production. The remaining three arguments are stored
as-is with no validation.
The XMLSerializer emits DocumentType nodes as:
<!DOCTYPE name[ PUBLIC pubid][ SYSTEM sysid][ [internalSubset]]>
All fields are pushed into the output buffer verbatim — no escaping, no quoting added.
internalSubset injection: The serializer wraps internalSubset with [ and ]. A value
containing ]> closes the internal subset and the DOCTYPE declaration at the injection point.
Any content after ]> in internalSubset appears outside the DOCTYPE in the serialized output as
raw XML markup. Reported by @TharVid (GHSA-f6ww-3ggp-fr8h). Affected: @xmldom/xmldom ≥ 0.9.0
via createDocumentType API; 0.8.x only via direct property write.
publicId injection: The serializer emits publicId verbatim after PUBLIC with no
quoting added. A value containing an injected system identifier (e.g.,
"pubid" SYSTEM "evil") breaks the intended quoting context, injecting a fake SYSTEM entry
into the serialized DOCTYPE declaration. Identified during internal security research. Affected:
both branches, all versions back to 0.1.0.
systemId injection: The serializer emits systemId verbatim. A value containing >
terminates the DOCTYPE declaration early; content after > appears as raw XML markup outside
the DOCTYPE context. Identified during internal security research. Affected: both branches, all
versions back to 0.1.0.
The parse path is safe: the SAX parser enforces the PubidLiteral and SystemLiteral grammar
productions, which exclude the relevant characters, and the internal subset parser only accepts a
subset it can structurally validate. The vulnerability is reachable only through programmatic
createDocumentType calls with attacker-controlled arguments.
Affected code
lib/dom.js — createDocumentType (lines 898–910):
createDocumentType: function (qualifiedName, publicId, systemId, internalSubset) {
validateQualifiedName(qualifiedName); // only qualifiedName is validated
var node = new DocumentType(PDC);
node.name = qualifiedName;
node.nodeName = qualifiedName;
node.publicId = publicId || ''; // stored verbatim
node.systemId = systemId || ''; // stored verbatim
node.internalSubset = internalSubset || ''; // stored verbatim
node.childNodes = new NodeList();
return node;
},
lib/dom.js — serializer DOCTYPE case (lines 2948–2964):
case DOCUMENT_TYPE_NODE:
var pubid = node.publicId;
var sysid = node.systemId;
buf.push(g.DOCTYPE_DECL_START, ' ', node.name);
if (pubid) {
buf.push(' ', g.PUBLIC, ' ', pubid);
if (sysid && sysid !== '.') {
buf.push(' ', sysid);
}
} else if (sysid && sysid !== '.') {
buf.push(' ', g.SYSTEM, ' ', sysid);
}
if (node.internalSubset) {
buf.push(' [', node.internalSubset, ']'); // internalSubset emitted verbatim
}
buf.push('>');
return;
PoC
internalSubset injection
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
'root',
'',
'',
']><injected/><![CDATA['
);
const doc = impl.createDocument(null, 'root', doctype);
const xml = new XMLSerializer().serializeToString(doc);
console.log(xml);
// <!DOCTYPE root []><injected/><![CDATA[]><root/>
// ^^^^^^^^^^ injected element outside DOCTYPE
publicId quoting context break
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
'root',
'"injected PUBLIC_ID" SYSTEM "evil"',
'',
''
);
const doc = impl.createDocument(null, 'root', doctype);
console.log(new XMLSerializer().serializeToString(doc));
// <!DOCTYPE root PUBLIC "injected PUBLIC_ID" SYSTEM "evil"><root/>
// quoting context broken — SYSTEM entry injected
systemId injection
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
'root',
'',
'"sysid"><injected attr="pwn"/>',
''
);
const doc = impl.createDocument(null, 'root', doctype);
console.log(new XMLSerializer().serializeToString(doc));
// <!DOCTYPE root SYSTEM "sysid"><injected attr="pwn"/>><root/>
// > in sysid closes DOCTYPE early; <injected/> appears as sibling element
Impact
An application that programmatically constructs DocumentType nodes from user-controlled data and
then serializes the document can emit a DOCTYPE declaration where the internal subset is closed
early or where injected SYSTEM entities or other declarations appear in the serialized output.
Downstream XML parsers that re-parse the serialized output and expand entities from the injected DOCTYPE declarations may be susceptible to XXE-class attacks if they enable entity expansion.
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 tocreateDocumentType()or write untrusted values directly to aDocumentTypenode'spublicId,systemId, orinternalSubsetproperties 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 validates the DocumentType node's publicId, systemId, and internalSubset fields before emitting the DOCTYPE declaration and throws InvalidStateError if any field contains an injection sequence:
publicId: throws if non-empty and does not match the XMLPubidLiteralproduction (XML 1.0 [12])systemId: throws if non-empty and does not match the XMLSystemLiteralproduction (XML 1.0 [11])internalSubset: throws if it contains]>(which closes the internal subset and DOCTYPE declaration early)
All three checks apply regardless of how the invalid value entered the node — whether via createDocumentType arguments or a subsequent direct property write.
PoC — fixed path
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
// internalSubset injection
const dt1 = impl.createDocumentType('root', '', '', ']><injected/><![CDATA[');
const doc1 = impl.createDocument(null, 'root', dt1);
// Default (unchanged): verbatim — injection present
console.log(new XMLSerializer().serializeToString(doc1));
// <!DOCTYPE root []><injected/><![CDATA[]><root/>
// Opt-in guard: throws InvalidStateError
try {
new XMLSerializer().serializeToString(doc1, { requireWellFormed: true });
} catch (e) {
console.log(e.name, e.message);
// InvalidStateError: DocumentType internalSubset contains "]>"
}
The guard also covers post-creation property writes:
const dt2 = impl.createDocumentType('root', '', '');
dt2.systemId = '"sysid"><injected attr="pwn"/>';
const doc2 = impl.createDocument(null, 'root', dt2);
new XMLSerializer().serializeToString(doc2, { requireWellFormed: true });
// InvalidStateError: DocumentType systemId is not a valid SystemLiteral
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 permits verbatim serialization of DOCTYPE fields. 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 deployments.
Residual limitation
createDocumentType(qualifiedName, publicId, systemId[, internalSubset]) does not validate publicId, systemId, or internalSubset at creation time. This creation-time validation is a breaking change and is deferred to a future breaking release.
When the default serialization path is used (without requireWellFormed: true), all three fields are 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-41674"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T20:19:12Z",
"nvd_published_at": "2026-05-07T04:16:33Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe package serializes `DocumentType` node fields (`internalSubset`, `publicId`, `systemId`) verbatim\nwithout any escaping or validation. When these fields are set programmatically to attacker-controlled\nstrings, `XMLSerializer.serializeToString` can produce output where the DOCTYPE declaration is\nterminated early and arbitrary markup appears outside it.\n\n---\n\n## Details\n\n`DOMImplementation.createDocumentType(qualifiedName, publicId, systemId, internalSubset)` validates\nonly `qualifiedName` against the XML QName production. The remaining three arguments are stored\nas-is with no validation.\n\nThe XMLSerializer emits `DocumentType` nodes as:\n\n```\n\u003c!DOCTYPE name[ PUBLIC pubid][ SYSTEM sysid][ [internalSubset]]\u003e\n```\n\nAll fields are pushed into the output buffer verbatim \u2014 no escaping, no quoting added.\n\n**`internalSubset` injection:** The serializer wraps `internalSubset` with ` [` and `]`. A value\ncontaining `]\u003e` closes the internal subset and the DOCTYPE declaration at the injection point.\nAny content after `]\u003e` in `internalSubset` appears outside the DOCTYPE in the serialized output as\nraw XML markup. Reported by @TharVid (GHSA-f6ww-3ggp-fr8h). Affected: `@xmldom/xmldom` \u2265 0.9.0\nvia `createDocumentType` API; 0.8.x only via direct property write.\n\n**`publicId` injection:** The serializer emits `publicId` verbatim after `PUBLIC` with no\nquoting added. A value containing an injected system identifier (e.g.,\n`\"pubid\" SYSTEM \"evil\"`) breaks the intended quoting context, injecting a fake SYSTEM entry\ninto the serialized DOCTYPE declaration. Identified during internal security research. Affected:\nboth branches, all versions back to 0.1.0.\n\n**`systemId` injection:** The serializer emits `systemId` verbatim. A value containing `\u003e`\nterminates the DOCTYPE declaration early; content after `\u003e` appears as raw XML markup outside\nthe DOCTYPE context. Identified during internal security research. Affected: both branches, all\nversions back to 0.1.0.\n\nThe parse path is safe: the SAX parser enforces the `PubidLiteral` and `SystemLiteral` grammar\nproductions, which exclude the relevant characters, and the internal subset parser only accepts a\nsubset it can structurally validate. The vulnerability is reachable only through programmatic\n`createDocumentType` calls with attacker-controlled arguments.\n\n---\n\n## Affected code\n\n**`lib/dom.js` \u2014 `createDocumentType` (lines 898\u2013910):**\n\n```js\ncreateDocumentType: function (qualifiedName, publicId, systemId, internalSubset) {\n validateQualifiedName(qualifiedName); // only qualifiedName is validated\n var node = new DocumentType(PDC);\n node.name = qualifiedName;\n node.nodeName = qualifiedName;\n node.publicId = publicId || \u0027\u0027; // stored verbatim\n node.systemId = systemId || \u0027\u0027; // stored verbatim\n node.internalSubset = internalSubset || \u0027\u0027; // stored verbatim\n node.childNodes = new NodeList();\n return node;\n},\n```\n\n**`lib/dom.js` \u2014 serializer DOCTYPE case (lines 2948\u20132964):**\n\n```js\ncase DOCUMENT_TYPE_NODE:\n var pubid = node.publicId;\n var sysid = node.systemId;\n buf.push(g.DOCTYPE_DECL_START, \u0027 \u0027, node.name);\n if (pubid) {\n buf.push(\u0027 \u0027, g.PUBLIC, \u0027 \u0027, pubid);\n if (sysid \u0026\u0026 sysid !== \u0027.\u0027) {\n buf.push(\u0027 \u0027, sysid);\n }\n } else if (sysid \u0026\u0026 sysid !== \u0027.\u0027) {\n buf.push(\u0027 \u0027, g.SYSTEM, \u0027 \u0027, sysid);\n }\n if (node.internalSubset) {\n buf.push(\u0027 [\u0027, node.internalSubset, \u0027]\u0027); // internalSubset emitted verbatim\n }\n buf.push(\u0027\u003e\u0027);\n return;\n```\n\n---\n\n## PoC\n\n### internalSubset injection\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst impl = new DOMImplementation();\nconst doctype = impl.createDocumentType(\n \u0027root\u0027,\n \u0027\u0027,\n \u0027\u0027,\n \u0027]\u003e\u003cinjected/\u003e\u003c![CDATA[\u0027\n);\nconst doc = impl.createDocument(null, \u0027root\u0027, doctype);\nconst xml = new XMLSerializer().serializeToString(doc);\nconsole.log(xml);\n// \u003c!DOCTYPE root []\u003e\u003cinjected/\u003e\u003c![CDATA[]\u003e\u003croot/\u003e\n// ^^^^^^^^^^ injected element outside DOCTYPE\n```\n\n### publicId quoting context break\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst impl = new DOMImplementation();\nconst doctype = impl.createDocumentType(\n \u0027root\u0027,\n \u0027\"injected PUBLIC_ID\" SYSTEM \"evil\"\u0027,\n \u0027\u0027,\n \u0027\u0027\n);\nconst doc = impl.createDocument(null, \u0027root\u0027, doctype);\nconsole.log(new XMLSerializer().serializeToString(doc));\n// \u003c!DOCTYPE root PUBLIC \"injected PUBLIC_ID\" SYSTEM \"evil\"\u003e\u003croot/\u003e\n// quoting context broken \u2014 SYSTEM entry injected\n```\n\n### systemId injection\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst impl = new DOMImplementation();\nconst doctype = impl.createDocumentType(\n \u0027root\u0027,\n \u0027\u0027,\n \u0027\"sysid\"\u003e\u003cinjected attr=\"pwn\"/\u003e\u0027,\n \u0027\u0027\n);\nconst doc = impl.createDocument(null, \u0027root\u0027, doctype);\nconsole.log(new XMLSerializer().serializeToString(doc));\n// \u003c!DOCTYPE root SYSTEM \"sysid\"\u003e\u003cinjected attr=\"pwn\"/\u003e\u003e\u003croot/\u003e\n// \u003e in sysid closes DOCTYPE early; \u003cinjected/\u003e appears as sibling element\n```\n\n---\n\n## Impact\n\nAn application that programmatically constructs `DocumentType` nodes from user-controlled data and\nthen serializes the document can emit a DOCTYPE declaration where the internal subset is closed\nearly or where injected SYSTEM entities or other declarations appear in the serialized output.\n\nDownstream XML parsers that re-parse the serialized output and expand entities from the injected\nDOCTYPE declarations may be susceptible to XXE-class attacks if they enable entity expansion.\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 `createDocumentType()` or write untrusted values directly to a\n\u003e `DocumentType` node\u0027s `publicId`, `systemId`, or `internalSubset` properties should audit\n\u003e all `serializeToString()` 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 validates the `DocumentType` node\u0027s `publicId`, `systemId`, and `internalSubset` fields before emitting the DOCTYPE declaration and throws `InvalidStateError` if any field contains an injection sequence:\n\n- **`publicId`**: throws if non-empty and does not match the XML `PubidLiteral` production (XML 1.0 [12])\n- **`systemId`**: throws if non-empty and does not match the XML `SystemLiteral` production (XML 1.0 [11])\n- **`internalSubset`**: throws if it contains `]\u003e` (which closes the internal subset and DOCTYPE declaration early)\n\nAll three checks apply regardless of how the invalid value entered the node \u2014 whether via `createDocumentType` arguments or a subsequent direct property write.\n\n### PoC \u2014 fixed path\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\nconst impl = new DOMImplementation();\n\n// internalSubset injection\nconst dt1 = impl.createDocumentType(\u0027root\u0027, \u0027\u0027, \u0027\u0027, \u0027]\u003e\u003cinjected/\u003e\u003c![CDATA[\u0027);\nconst doc1 = impl.createDocument(null, \u0027root\u0027, dt1);\n\n// Default (unchanged): verbatim \u2014 injection present\nconsole.log(new XMLSerializer().serializeToString(doc1));\n// \u003c!DOCTYPE root []\u003e\u003cinjected/\u003e\u003c![CDATA[]\u003e\u003croot/\u003e\n\n// Opt-in guard: throws InvalidStateError\ntry {\n new XMLSerializer().serializeToString(doc1, { requireWellFormed: true });\n} catch (e) {\n console.log(e.name, e.message);\n // InvalidStateError: DocumentType internalSubset contains \"]\u003e\"\n}\n```\n\nThe guard also covers post-creation property writes:\n\n```js\nconst dt2 = impl.createDocumentType(\u0027root\u0027, \u0027\u0027, \u0027\u0027);\ndt2.systemId = \u0027\"sysid\"\u003e\u003cinjected attr=\"pwn\"/\u003e\u0027;\nconst doc2 = impl.createDocument(null, \u0027root\u0027, dt2);\nnew XMLSerializer().serializeToString(doc2, { requireWellFormed: true });\n// InvalidStateError: DocumentType systemId is not a valid SystemLiteral\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 permits verbatim serialization of DOCTYPE fields. 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 deployments.\n\n### Residual limitation\n\n`createDocumentType(qualifiedName, publicId, systemId[, internalSubset])` does not validate `publicId`, `systemId`, or `internalSubset` at creation time. This creation-time validation is a breaking change and is deferred to a future breaking release.\n\nWhen the default serialization path is used (without `requireWellFormed: true`), all three fields are still emitted verbatim. Applications that do not pass `requireWellFormed: true` remain exposed.",
"id": "GHSA-f6ww-3ggp-fr8h",
"modified": "2026-05-08T20:10:16Z",
"published": "2026-04-22T20:19:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-f6ww-3ggp-fr8h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41674"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/372008f9ae0e20fd69f761c7b79e202598267314"
},
{
"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 injection through unvalidated DocumentType serialization"
}
GHSA-F8V8-JQRR-5MHQ
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-53674"
],
"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-f8v8-jqrr-5mhq",
"modified": "2024-11-27T00:31:41Z",
"published": "2024-11-27T00:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53674"
},
{
"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-FRV5-MFR5-Q7H5
Vulnerability from github – Published: 2024-05-07 18:30 – Updated: 2024-11-21 21:33An issue was discovered in Logpoint before 7.4.0. A path injection vulnerability is seen while adding a CSV enrichment source. The source_name parameter could be changed to an absolute path; this will write the CSV file to that path inside the /tmp directory.
{
"affected": [],
"aliases": [
"CVE-2024-33858"
],
"database_specific": {
"cwe_ids": [
"CWE-91"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-07T16:15:08Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Logpoint before 7.4.0. A path injection vulnerability is seen while adding a CSV enrichment source. The source_name parameter could be changed to an absolute path; this will write the CSV file to that path inside the /tmp directory.",
"id": "GHSA-frv5-mfr5-q7h5",
"modified": "2024-11-21T21:33:30Z",
"published": "2024-05-07T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33858"
},
{
"type": "WEB",
"url": "https://servicedesk.logpoint.com/hc/en-us/articles/18533668045725-Path-Injection-on-Enrichment-Sources-leading-to-arbitrary-file-write-in-tmp-folder"
},
{
"type": "WEB",
"url": "https://www.logpoint.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
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.