Common Weakness Enumeration

CWE-91

Allowed-with-Review

XML 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.

223 vulnerabilities reference this CWE, most recent first.

GHSA-45W3-2HVV-PFXQ

Vulnerability from github – Published: 2022-05-17 04:39 – Updated: 2024-03-05 00:06
VLAI
Summary
XML Injection in Apache Solr
Details

The DocumentAnalysisRequestHandler in Apache Solr before 4.3.1 does not properly use the EmptyEntityResolver, which allows remote attackers to have an unspecified impact via XML data containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue. NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-6407.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-6408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-07T23:22:41Z",
    "nvd_published_at": "2013-12-07T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The DocumentAnalysisRequestHandler in Apache Solr before 4.3.1 does not properly use the EmptyEntityResolver, which allows remote attackers to have an unspecified impact via XML data containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-6407.",
  "id": "GHSA-45w3-2hvv-pfxq",
  "modified": "2024-03-05T00:06:44Z",
  "published": "2022-05-17T04:39:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6408"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/lucene-solr/commit/7239a57a51ea0f4d05dd330ce5e15e4f72f72747"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/lucene-solr"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/SOLR-4881"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-1844.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-0029.html"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/CHANGES.txt?view=markup"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/11/29/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "XML Injection in Apache Solr"
}

GHSA-46C6-8824-H3WV

Vulnerability from github – Published: 2026-01-14 00:31 – Updated: 2026-01-14 00:31
VLAI
Details

Wondershare FamiSafe 1.0 contains an unquoted service path vulnerability in the FSService that allows local users to potentially execute code with elevated privileges. Attackers can exploit the unquoted path in C:\Program Files (x86)\Wondershare\FamiSafe\ to inject malicious code that would run with LocalSystem permissions during service startup.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T23:15:52Z",
    "severity": "HIGH"
  },
  "details": "Wondershare FamiSafe 1.0 contains an unquoted service path vulnerability in the FSService that allows local users to potentially execute code with elevated privileges. Attackers can exploit the unquoted path in C:\\Program Files (x86)\\Wondershare\\FamiSafe\\ to inject malicious code that would run with LocalSystem permissions during service startup.",
  "id": "GHSA-46c6-8824-h3wv",
  "modified": "2026-01-14T00:31:28Z",
  "published": "2026-01-14T00:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50902"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/50757"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wondershare-famisafe-fsservice-unquoted-service-path"
    },
    {
      "type": "WEB",
      "url": "https://www.wondershare.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4CGG-MFWM-V63X

Vulnerability from github – Published: 2022-10-18 12:00 – Updated: 2022-10-18 12:00
VLAI
Details

An XPath Injection vulnerability due to Improper Input Validation in the J-Web component of Juniper Networks Junos OS allows an authenticated attacker to add an XPath command to the XPath stream, which may allow chaining to other unspecified vulnerabilities, leading to a partial loss of confidentiality. This issue affects Juniper Networks Junos OS: all versions prior to 19.1R3-S9; 19.2 versions prior to 19.2R3-S6; 19.3 versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R2-S7, 19.4R3-S8; 20.1 versions prior to 20.1R3-S5; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S2; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R2-S2, 21.3R3; 21.4 versions prior to 21.4R1-S2, 21.4R2-S1, 21.4R3; 22.1 versions prior to 22.1R1-S1, 22.1R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-22243"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-18T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An XPath Injection vulnerability due to Improper Input Validation in the J-Web component of Juniper Networks Junos OS allows an authenticated attacker to add an XPath command to the XPath stream, which may allow chaining to other unspecified vulnerabilities, leading to a partial loss of confidentiality. This issue affects Juniper Networks Junos OS: all versions prior to 19.1R3-S9; 19.2 versions prior to 19.2R3-S6; 19.3 versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R2-S7, 19.4R3-S8; 20.1 versions prior to 20.1R3-S5; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S2; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R2-S2, 21.3R3; 21.4 versions prior to 21.4R1-S2, 21.4R2-S1, 21.4R3; 22.1 versions prior to 22.1R1-S1, 22.1R2.",
  "id": "GHSA-4cgg-mfwm-v63x",
  "modified": "2022-10-18T12:00:30Z",
  "published": "2022-10-18T12:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22243"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA69899"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4V25-P375-PCJC

Vulnerability from github – Published: 2024-06-13 18:31 – Updated: 2024-07-03 18:45
VLAI
Details

XPath Injection vulnerabilities in the blog and RSS functions of Modern Campus - Omni CMS 2023.1 allow a remote, unauthenticated attacker to obtain application information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-13T16:15:10Z",
    "severity": "MODERATE"
  },
  "details": "XPath Injection vulnerabilities in the blog and RSS functions of Modern Campus - Omni CMS 2023.1 allow a remote, unauthenticated attacker to obtain application information.",
  "id": "GHSA-4v25-p375-pcjc",
  "modified": "2024-07-03T18:45:01Z",
  "published": "2024-06-13T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35858"
    },
    {
      "type": "WEB",
      "url": "https://lp.constantcontactpages.com/cu/c2nSB5D/moderncampuscve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4W3V-83V8-MG94

Vulnerability from github – Published: 2022-05-24 17:06 – Updated: 2025-10-22 00:31
VLAI
Details

A remote code execution vulnerability exists when the Microsoft .NET Framework fails to validate input properly, aka '.NET Framework Remote Code Execution Injection Vulnerability'.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-0646"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-78",
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-14T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote code execution vulnerability exists when the Microsoft .NET Framework fails to validate input properly, aka \u0027.NET Framework Remote Code Execution Injection Vulnerability\u0027.",
  "id": "GHSA-4w3v-83v8-mg94",
  "modified": "2025-10-22T00:31:49Z",
  "published": "2022-05-24T17:06:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0646"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0646"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-0646"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/156930/SharePoint-Workflows-XOML-Injection.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4W3W-2RP5-G8JM

Vulnerability from github – Published: 2026-09-08 20:30 – Updated: 2026-09-08 20:30
VLAI
Summary
xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed
Details

Summary

Element.setAttribute() in @xmldom/xmldom bypasses attribute name validation by calling the private _createAttribute(name) method, which performs no validation. The public createAttribute() method correctly validates names against an anchored QName pattern, but setAttribute() never uses it. The serializer escapes attribute values but trusts attribute names, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The requireWellFormed: true option did not catch this.

Details

Element.setAttribute(name, value) creates attribute nodes by calling the private _createAttribute(name) method, which performs no validation on the name parameter. In contrast, the public Document.createAttribute(name) method validates the name against the QName production before creating the attribute node.

The result is a two-tier validation system where the most commonly used API (setAttribute) takes the unvalidated path:

  • doc.createAttribute("bad name") — throws INVALID_CHARACTER_ERR (correct).
  • el.setAttribute("bad name", "value") — succeeds silently (vulnerable).

The serializer emits attribute names verbatim into the output. Because attribute values ARE escaped (quotes, ampersands, etc.), the injection must occur through the name. An attacker can terminate the current attribute and inject new ones by including quote and space characters in the attribute name.

Root Cause

  1. setAttribute() calls _createAttribute() (private, no validation) instead of createAttribute() (public, validates against QName).
  2. The serializer trusts attribute names and emits them unescaped.
  3. The serializer's requireWellFormed code path did not validate attribute names during serialization.

Proof of Concept

const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');

const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);

// The attribute name contains a closing quote, a space, and a new attribute
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');

const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// <root class="safe" onclick="alert(1)"/>
//
// The single setAttribute() call produced TWO attributes:
//   1. class="safe"
//   2. onclick="alert(1)"
//
// requireWellFormed: true did NOT prevent the injection.

Demonstrating the validation gap

// Public createAttribute correctly rejects invalid names:
try {
  doc.createAttribute('class="safe" onclick');
} catch (e) {
  console.log('createAttribute rejects:', e.message);
}

// But setAttribute (which uses _createAttribute) accepts the same input:
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
// No error thrown

Impact

Applications that use setAttribute() with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:

  • Cross-Site Scripting (XSS): Injecting event handler attributes into HTML output consumed by browsers.
  • Security attribute override: Overriding security-relevant attributes such as integrity, nonce, sandbox, or Content-Security-Policy meta attributes.
  • Validation bypass: The public createAttribute() API validates while setAttribute() does not, creating an inconsistent security boundary that developers cannot rely on.
  • requireWellFormed bypass: Applications that adopted requireWellFormed: true as a mitigation for prior CVEs remained vulnerable.

@xmldom/xmldom can also be used inside browsers, where it mirrors the DOM API. Unlike the browser's setAttribute(), which rejects an invalid attribute name with InvalidCharacterError, xmldom accepts it — developers may assume the same safety and skip validation.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that serialize untrusted DOM content should audit all serializeToString() call sites and add it.

When { requireWellFormed: true } is passed, the serializer now validates each serialized attribute's qualified name against the XML QName production and throws InvalidStateError before emitting it. This covers ordinary attribute names and synthesized xmlns:PREFIX namespace declarations (the namespace-prefix sub-vector).

Fixed under requireWellFormed: true in @xmldom/xmldom 0.9.11 and 0.8.14. Default serialization is unchanged.

PoC — fixed path

const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');

// Default (unchanged): verbatim — injection present
console.log(new XMLSerializer().serializeToString(doc));
// <root class="safe" onclick="alert(1)"/>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The attribute name "class="safe" onclick" is not a valid XML QName
}

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec defines a require well-formed flag whose default value is false. With the flag unset, the serializer emits attribute names verbatim, matching the XMLSerializer behavior of Chrome, Firefox, and Safari. Unconditionally throwing would be a behavioral breaking change with no spec justification; the opt-in requireWellFormed: true flag lets applications that require injection safety enable strict mode without breaking existing code.

Residual limitation

setAttribute(name, value) does not validate name at creation time (unlike the public createAttribute(), which already does). Making setAttribute() reject invalid names unconditionally is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without requireWellFormed: true), attribute names set via setAttribute() are still emitted verbatim; applications that do not pass requireWellFormed: true remain exposed.

Creation-time validation is tracked in a public issue on the next breaking-release milestone (filed at publication — issue link to be added), targeting the next breaking release.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.9.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.0"
            },
            {
              "fixed": "0.8.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-83605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T20:30:51Z",
    "nvd_published_at": "2026-09-01T15:17:38Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Element.setAttribute()` in `@xmldom/xmldom` bypasses attribute name validation by calling the private `_createAttribute(name)` method, which performs no validation. The public `createAttribute()` method correctly validates names against an anchored `QName` pattern, but `setAttribute()` never uses it. The serializer escapes attribute *values* but trusts attribute *names*, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The `requireWellFormed: true` option did not catch this.\n\n## Details\n\n`Element.setAttribute(name, value)` creates attribute nodes by calling the private `_createAttribute(name)` method, which performs no validation on the `name` parameter. In contrast, the public `Document.createAttribute(name)` method validates the name against the `QName` production before creating the attribute node.\n\nThe result is a two-tier validation system where the most commonly used API (`setAttribute`) takes the unvalidated path:\n\n- `doc.createAttribute(\"bad name\")` \u2014 throws `INVALID_CHARACTER_ERR` (correct).\n- `el.setAttribute(\"bad name\", \"value\")` \u2014 succeeds silently (vulnerable).\n\nThe serializer emits attribute names verbatim into the output. Because attribute values ARE escaped (quotes, ampersands, etc.), the injection must occur through the name. An attacker can terminate the current attribute and inject new ones by including quote and space characters in the attribute name.\n\n### Root Cause\n\n1. `setAttribute()` calls `_createAttribute()` (private, no validation) instead of `createAttribute()` (public, validates against `QName`).\n2. The serializer trusts attribute names and emits them unescaped.\n3. The serializer\u0027s `requireWellFormed` code path did not validate attribute names during serialization.\n\n## Proof of Concept\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst impl = new DOMImplementation();\nconst serializer = new XMLSerializer();\nconst doc = impl.createDocument(null, \u0027root\u0027, null);\n\n// The attribute name contains a closing quote, a space, and a new attribute\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n\nconst output = serializer.serializeToString(doc, { requireWellFormed: true });\nconsole.log(output);\n// \u003croot class=\"safe\" onclick=\"alert(1)\"/\u003e\n//\n// The single setAttribute() call produced TWO attributes:\n//   1. class=\"safe\"\n//   2. onclick=\"alert(1)\"\n//\n// requireWellFormed: true did NOT prevent the injection.\n```\n\n### Demonstrating the validation gap\n\n```js\n// Public createAttribute correctly rejects invalid names:\ntry {\n  doc.createAttribute(\u0027class=\"safe\" onclick\u0027);\n} catch (e) {\n  console.log(\u0027createAttribute rejects:\u0027, e.message);\n}\n\n// But setAttribute (which uses _createAttribute) accepts the same input:\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n// No error thrown\n```\n\n## Impact\n\nApplications that use `setAttribute()` with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:\n\n- **Cross-Site Scripting (XSS)**: Injecting event handler attributes into HTML output consumed by browsers.\n- **Security attribute override**: Overriding security-relevant attributes such as `integrity`, `nonce`, `sandbox`, or `Content-Security-Policy` meta attributes.\n- **Validation bypass**: The public `createAttribute()` API validates while `setAttribute()` does not, creating an inconsistent security boundary that developers cannot rely on.\n- **requireWellFormed bypass**: Applications that adopted `requireWellFormed: true` as a mitigation for prior CVEs remained vulnerable.\n\n`@xmldom/xmldom` can also be used inside browsers, where it mirrors the DOM API. Unlike the browser\u0027s `setAttribute()`, which rejects an invalid attribute name with `InvalidCharacterError`, xmldom accepts it \u2014 developers may assume the same safety and skip validation.\n\n## Fix Applied\n\n\u003e **\u26a0 Opt-in required.** Protection is not automatic. Existing serialization calls remain\n\u003e vulnerable unless `{ requireWellFormed: true }` is explicitly passed. Applications that\n\u003e serialize untrusted DOM content should audit all `serializeToString()` call sites and add it.\n\nWhen `{ requireWellFormed: true }` is passed, the serializer now validates each serialized attribute\u0027s qualified name against the XML `QName` production and throws `InvalidStateError` before emitting it. This covers ordinary attribute names **and** synthesized `xmlns:PREFIX` namespace declarations (the namespace-prefix sub-vector).\n\nFixed under `requireWellFormed: true` in `@xmldom/xmldom` **0.9.11** and **0.8.14**. Default serialization is unchanged.\n\n### PoC \u2014 fixed path\n\n```js\nconst { DOMImplementation, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst doc = new DOMImplementation().createDocument(null, \u0027root\u0027, null);\ndoc.documentElement.setAttribute(\u0027class=\"safe\" onclick\u0027, \u0027alert(1)\u0027);\n\n// Default (unchanged): verbatim \u2014 injection present\nconsole.log(new XMLSerializer().serializeToString(doc));\n// \u003croot class=\"safe\" onclick=\"alert(1)\"/\u003e\n\n// Opt-in guard: throws InvalidStateError before serializing\ntry {\n  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });\n} catch (e) {\n  console.log(e.name, e.message);\n  // InvalidStateError: The attribute name \"class=\"safe\" onclick\" is not a valid XML QName\n}\n```\n\n### Why the default stays verbatim\n\nThe W3C DOM Parsing and Serialization spec defines a `require well-formed` flag whose **default value is `false`**. With the flag unset, the serializer emits attribute names verbatim, matching the `XMLSerializer` behavior of Chrome, Firefox, and Safari. Unconditionally throwing would be a behavioral breaking change with no spec justification; the opt-in `requireWellFormed: true` flag lets applications that require injection safety enable strict mode without breaking existing code.\n\n### Residual limitation\n\n`setAttribute(name, value)` does not validate `name` at creation time (unlike the public `createAttribute()`, which already does). Making `setAttribute()` reject invalid names unconditionally is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without `requireWellFormed: true`), attribute names set via `setAttribute()` are still emitted verbatim; applications that do not pass `requireWellFormed: true` remain exposed.\n\nCreation-time validation is tracked in a public issue on the next breaking-release milestone (filed at publication \u2014 issue link to be added), targeting the next breaking release.",
  "id": "GHSA-4w3w-2rp5-g8jm",
  "modified": "2026-09-08T20:30:51Z",
  "published": "2026-09-08T20:30:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-4w3w-2rp5-g8jm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1050"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/cba1321218b069182695813fa7565653708e172e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/d8212e632507eaf1d9f609657dd4c56abeb12d44"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xmldom/xmldom"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.8.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.9.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed"
}

GHSA-4X28-F32Q-R2QV

Vulnerability from github – Published: 2025-10-21 12:31 – Updated: 2025-10-23 15:30
VLAI
Details

Zohocorp ManageEngine EndPoint Central versions 11.4.2516.1 and prior are vulnerable to XML Injection.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-7473"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-21T11:15:34Z",
    "severity": "MODERATE"
  },
  "details": "Zohocorp ManageEngine EndPoint Central versions\u00a011.4.2516.1 and prior are vulnerable to XML Injection.",
  "id": "GHSA-4x28-f32q-r2qv",
  "modified": "2025-10-23T15:30:31Z",
  "published": "2025-10-21T12:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7473"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/desktop-central/parsing-xml-data.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-536H-WXCG-VP88

Vulnerability from github – Published: 2024-11-27 00:31 – Updated: 2024-11-27 00:31
VLAI
Details

An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11622"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-611",
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T22:15:17Z",
    "severity": "HIGH"
  },
  "details": "An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.",
  "id": "GHSA-536h-wxcg-vp88",
  "modified": "2024-11-27T00:31:41Z",
  "published": "2024-11-27T00:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11622"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04731en_us"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-56G4-WF8M-979X

Vulnerability from github – Published: 2024-11-27 00:31 – Updated: 2024-11-27 00:31
VLAI
Details

An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-53675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-611",
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T22:15:18Z",
    "severity": "HIGH"
  },
  "details": "An XML external entity injection (XXE) vulnerability in HPE Insight Remote Support may allow remote users to disclose information in certain cases.",
  "id": "GHSA-56g4-wf8m-979x",
  "modified": "2024-11-27T00:31:41Z",
  "published": "2024-11-27T00:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53675"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04731en_us"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5CX9-PQMM-54RV

Vulnerability from github – Published: 2022-05-17 03:13 – Updated: 2022-05-17 03:13
VLAI
Details

IBM BigFix Remote Control before 9.1.3 allows remote attackers to conduct XML injection attacks via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-2932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-91"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-11-30T11:59:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM BigFix Remote Control before 9.1.3 allows remote attackers to conduct XML injection attacks via unspecified vectors.",
  "id": "GHSA-5cx9-pqmm-54rv",
  "modified": "2022-05-17T03:13:19Z",
  "published": "2022-05-17T03:13:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-2932"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg1IV89787"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21991882"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94983"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-5
Implementation

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.