CVE-2026-41675: @xmldom/xmldom Xmldom Has XML Node Injection Vulnerability

HIGH
Advisory Identifier: GHSA-x6wf-f3px-wcqx
CWE-91
Published
Advisory Summary

CVE-2026-41675 is a HIGH xmldom has xml node injection vulnerability (CWE-91: XML Injection (aka Blind XPath Injection)) affecting @xmldom/xmldom libraries in the npm ecosystem. The issue involves xmldom has xml node injection through unvalidated processing instruction serialization. Remediation is available by upgrading affected packages to version 0.8.13, 0.9.10.

CVE-2026-41675 at a Glance

CVE Identifier CVE-2026-41675
GHSA Identifier GHSA-x6wf-f3px-wcqx
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-91: XML Injection (aka Blind XPath Injection)
Affected Product @xmldom/xmldom
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-41675

To remediate this vulnerability, upgrade all affected @xmldom/xmldom dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@xmldom/xmldom fixed: 0.8.13
npm install @xmldom/xmldom@0.8.13
@xmldom/xmldom fixed: 0.9.10
npm install @xmldom/xmldom@0.9.10
xmldom fixed: Latest secure release
npm install xmldom@Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @xmldom/xmldom

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-41675, inspect your project dependencies using npm:

npm ls @xmldom/xmldom

Analyze the terminal output to locate any version of @xmldom/xmldom in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.8.13), your application is affected.

Note: The npm ls @xmldom/xmldom command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-91: XML Injection (aka Blind XPath Injection), where 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. In @xmldom/xmldom, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary 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):** ```js 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):** ```js 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):** ```js 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) ```js 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) ```js 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](https://github.com/xmldom/xmldom/pull/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 to `createProcessingInstruction()` or mutate PI nodes with untrusted input > (via `.data =` or `CharacterData` mutation methods) should audit all `serializeToString()` > 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`: 1. **Target check**: throws `InvalidStateError` if the PI target contains a `:` character or is an ASCII case-insensitive match for `"xml"`. 2. **Data Char check**: throws `InvalidStateError` if the PI data contains characters outside the XML Char production. 3. **Data sequence check**: throws `InvalidStateError` if 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 ```js 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: ```js // 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.

CVE-2026-41675 Affected @xmldom/xmldom Versions

3 component(s)
Fixed Versions:
0.8.130.9.10
Product / Package Ecosystem Affected Versions Fixed Version
@xmldom/xmldom
npm
< 0.8.13
0.8.13
@xmldom/xmldom
npm
≥ 0.9.0
< 0.9.10
0.9.10
xmldom
npm
≤ 0.6.0

References

Frequently Asked Questions

What is CVE-2026-41675?
CVE-2026-41675 is a security vulnerability in @xmldom/xmldom involving xmldom has XML node injection through unvalidated processing instruction serialization under CWE-91: XML Injection (aka Blind XPath Injection).
Which @xmldom/xmldom versions are affected?
Affected versions include releases prior to 0.8.13, 0.9.10 across affected packages: @xmldom/xmldom, xmldom.
What version fixes CVE-2026-41675?
Upgrading to 0.8.13, 0.9.10 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @xmldom/xmldom affected?
Yes, @xmldom/xmldom is affected in releases prior to 0.8.13, 0.9.10. Upgrade your dependency to 0.8.13, 0.9.10 or later.
Is xmldom affected?
Yes, xmldom is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What CWE is associated with CVE-2026-41675?
CVE-2026-41675 is classified under CWE-91: XML Injection (aka Blind XPath Injection) (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.).
How can I check npm dependencies for CVE-2026-41675?
Run the dependency tree command: 'npm ls @xmldom/xmldom'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-x6wf-f3px-wcqx",
  "modified" : "2026-05-08T20:10:13Z",
  "published" : "2026-04-22T20:17:58Z",
  "aliases" : [ "CVE-2026-41675" ],
  "summary" : "xmldom has XML node injection through unvalidated processing instruction serialization",
  "details" : "## Summary\n\nThe 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.\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 `<?`, the target, a space, `node.data`, and `?>` directly.\n\nThat 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.\n\nThe 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.\n\n---\n\n## Affected code\n\n**`lib/dom.js` — `createProcessingInstruction` (lines 2240–2246):**\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 `?>` is stored as-is.\n\n**`lib/dom.js` — serializer PI case (line 2966):**\n\n```js\ncase PROCESSING_INSTRUCTION_NODE:\n    return buf.push('<?', node.target, ' ', node.data, '?>');\n```\n\n`node.data` is emitted verbatim. If it contains `?>`, that sequence terminates the PI in the output\nstream and the remainder appears as active XML markup.\n\n**Contrast — CDATA (line 2945, patched):**\n\n```js\ncase CDATA_SECTION_NODE:\n    return buf.push(g.CDATA_START, node.data.replace(/]]>/g, ']]]]><![CDATA[>'), g.CDATA_END);\n```\n\n---\n\n## PoC\n\n### Minimal (from @tlsbollei report, 2026-04-01)\n\n```js\nconst { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');\n\nconst doc = new DOMImplementation().createDocument(null, 'r', null);\ndoc.documentElement.appendChild(\n    doc.createProcessingInstruction('a', '?><z/><?q ')\n);\nconsole.log(new XMLSerializer().serializeToString(doc));\n// <r><?a ?><z/><?q ?></r>\n//          ^^^^ injected <z/> element is active markup\n```\n\n### With re-parse verification (from @tlsbollei report)\n\n```js\nconst assert = require('assert');\nconst { DOMParser, XMLSerializer } = require('@xmldom/xmldom');\n\nconst doc = new DOMParser().parseFromString('<r/>', 'application/xml');\ndoc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));\nconst xml = new XMLSerializer().serializeToString(doc);\nassert.strictEqual(new DOMParser().parseFromString(xml, 'application/xml')\n    .getElementsByTagName('z').length, 1); // passes — z is a real element\n```\n\n---\n\n## Impact\n\nAn 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.\n\nIn 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.\n\nAs 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.\n\n---\n\n## Disclosure\n\nThis vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via\n[xmldom/xmldom#987](https://github.com/xmldom/xmldom/pull/987), which was subsequently closed\nwithout being merged.\n\n---\n\n## Fix Applied\n\n> **⚠ Opt-in required.** Protection is not automatic. Existing serialization calls remain\n> vulnerable unless `{ requireWellFormed: true }` is explicitly passed. Applications that pass\n> untrusted data to `createProcessingInstruction()` or mutate PI nodes with untrusted input\n> (via `.data =` or `CharacterData` mutation methods) should audit all `serializeToString()`\n> 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 `?>`. This check applies regardless of how `?>` entered the node — whether via `createProcessingInstruction` directly or a subsequent mutation (`.data =`, `CharacterData` methods).\n\nOn `@xmldom/xmldom` ≥ 0.9.10, the serializer additionally applies the full W3C DOM Parsing §3.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 `?>`.\n\nOn `@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.\n\n### PoC — fixed path\n\n```js\nconst { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');\n\nconst doc = new DOMImplementation().createDocument(null, 'r', null);\ndoc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));\n\n// Default (unchanged): verbatim — injection present\nconst unsafe = new XMLSerializer().serializeToString(doc);\nconsole.log(unsafe);\n// <r><?a ?><z/><?q ?></r>\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 \"?>\"\n}\n```\n\nThe guard catches `?>` regardless of when it was introduced:\n\n```js\n// Post-creation mutation: also caught at serialization time\nconst pi = doc.createProcessingInstruction('target', 'safe data');\ndoc.documentElement.appendChild(pi);\npi.data = 'safe?><injected/>';\nnew XMLSerializer().serializeToString(doc, { requireWellFormed: true });\n// InvalidStateError: The ProcessingInstruction data contains \"?>\"\n```\n\n### Why the default stays verbatim\n\nThe 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.\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 (§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.\n\nWhen 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.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@xmldom/xmldom"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.8.13"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@xmldom/xmldom"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.9.0"
      }, {
        "fixed" : "0.9.10"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "xmldom"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "0.6.0"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-91" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-22T20:17:58Z",
    "nvd_published_at" : "2026-05-07T04:16:33Z"
  }
}