chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security] by renovate[bot] · Pull Request #3185 · adobe/spacecat-api-service

renovate · 2026-09-02T15:55:45Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@xmldom/xmldom	`0.9.10` → `0.9.12`

xmldom: XML injection via unsafe CDATA serialization allows attacker-controlled markup insertion

CVE-2026-34601 / GHSA-wh4c-j3r5-mjhp

More information

Details

Summary

@xmldom/xmldom allows attacker-controlled strings containing the CDATA terminator ]]> to be inserted into a CDATASection node. During serialization, XMLSerializer emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became active XML markup in the serialized output, enabling XML structure
injection and downstream business-logic manipulation.

The sequence ]]> is not allowed inside CDATA content and must be rejected or safely handled during serialization. (MDN Web Docs)

Attack surface

Document.createCDATASection(data) is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate ]]> in mutation methods — only createCDATASection carries that guard. The following paths therefore also allow ]]> to enter a CDATASection node and reach the serializer:

CharacterData.appendData()
CharacterData.replaceData()
CharacterData.insertData()
Direct assignment to .data
Direct assignment to .textContent

(Note: assigning to .nodeValue does not update .data in this implementation — the serializer reads .data directly — so .nodeValue is not an exploitable path.)

Parse path

Parsing XML that contains a CDATA section is not affected. The SAX parser's non-greedy CDSect regex stops at the first ]]>, so parsed CDATA data never contains the terminator.

Impact

If an application uses xmldom to generate "trusted" XML documents that embed untrusted user input inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document.

This can lead to:

Integrity violation of generated XML documents.
Business-logic injection in downstream consumers (e.g., injecting <approved>true</approved>, <role>admin</role>, workflow flags, or other security-relevant elements).
Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear.

This issue does not require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup.

Root Cause (with file + line numbers)

File: lib/dom.js

1. No validation in `createCDATASection`

createCDATASection: function (data) accepts any string and appends it directly.

Lines 2216–2221 (0.9.8)

2. Unsafe CDATA serialization

Serializer prints CDATA sections as:

<![CDATA[ + node.data + ]]>

without handling ]]> in the data.

Lines 2919–2920 (0.9.8)

Because CDATA content is emitted verbatim, an embedded ]]> closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML.

Proof of Concept — Fix A: `createCDATASection` now throws

On patched versions, passing ]]> directly to createCDATASection throws InvalidCharacterError instead of silently accepting the payload:

const { DOMImplementation } = require('./lib');

const doc = new DOMImplementation().createDocument(null, 'root', null);
try {
  doc.createCDATASection('SAFE]]><injected attr="pwn"/>');
  console.log('VULNERABLE — no error thrown');
} catch (e) {
  console.log('FIXED — threw:', e.name); // InvalidCharacterError
}

Expected output on patched versions:

FIXED — threw: InvalidCharacterError

Proof of Concept — Fix B: mutation vector now safe

On patched versions, injecting ]]> via a mutation method (appendData, replaceData, .data =, .textContent =) no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text:

const { DOMImplementation, XMLSerializer } = require('./lib');
const { DOMParser } = require('./lib');

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

// Start with safe data, then mutate to include the terminator
const cdata = doc.createCDATASection('safe');
doc.documentElement.appendChild(cdata);
cdata.appendData(']]><injected attr="pwn"/><more>TEXT</more><![CDATA[');

const out = new XMLSerializer().serializeToString(doc);
console.log('Serialized:', out);

const reparsed = new DOMParser().parseFromString(out, 'text/xml');
const injected = reparsed.getElementsByTagName('injected').length > 0;
console.log('Injected element found in reparsed doc:', injected);
// VULNERABLE: true  |  FIXED: false

Expected output on patched versions:

Serialized: <root><![CDATA[safe]]]]><![CDATA[><injected attr="pwn"/><more>TEXT</more><![CDATA[]]></root>
Injected element found in reparsed doc: false

Fix Applied

Both mitigations were implemented:

Option A — Strict/spec-aligned: reject `]]>` in `createCDATASection()`

Document.createCDATASection(data) now throws InvalidCharacterError (per the WHATWG DOM spec) when data contains ]]>. This closes the direct entry point.

Code that previously passed a string containing ]]> to createCDATASection and relied on the silent/unsafe behaviour will now receive InvalidCharacterError. Use a mutation method such as appendData if you intentionally need ]]> in a CDATASection node's data (the serializer split in Option B will keep the output safe).

Option B — Defensive serialization: split the terminator during serialization

XMLSerializer now replaces every occurrence of ]]> in CDATA section data with the split sequence ]]]]><![CDATA[> before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how ]]> entered the node.

Update — 2026-04-xx (0.9.10 / 0.8.13)

`splitCDATASections` is deprecated

The CDATA split behavior introduced as Option B of this fix (replacing ]]> with]]]]><![CDATA[> during serialization) is deprecated as of 0.9.10 / 0.8.13.

This release introduces a requireWellFormed option on XMLSerializer.serializeToString(). When { requireWellFormed: true } is passed as the second argument, the serializer throws InvalidStateError if CDATA section data contains ]]> — this is the spec-aligned behavior (W3C DOM Parsing and Serialization, require well-formed flag) and the recommended migration path going forward.
The split behavior is now controlled by an explicit splitCDATASections option (default true, preserving the current behavior). The three serialization behaviors are:
| requireWellFormed | splitCDATASections | Behavior ||---|---|---|| false (default) | true (default) | Split ]]> → ]]]]><![CDATA[> (current behavior, deprecated) || true | — (ignored) | Throw InvalidStateError — spec-aligned, recommended |\ false | false | Emit verbatim — same as pre-0.9.9 behavior |

requireWellFormed: true takes precedence: the split path is unreachable when it is set.

Migration

Replace any reliance on the default split behavior with an explicit opt-in:

// After (explicit guard, spec-aligned): const xml = new XMLSerializer().serializeToString(doc, { requireWellFormed: true }); // Throws InvalidStateError if any CDATASection contains ']]>' ```

##### Removal timeline
Both the `splitCDATASections` option and the underlying `]]>` → `]]]]><![CDATA[>` split mechanics will be removed in the next breaking (`0.10.0`) release. After removal, the only behaviors will be verbatim (default) and `requireWellFormed: true` (throws).

Removal is tracked in [xmldom/xmldom#999](https://redirect.github.com/xmldom/xmldom/issues/999).

#### Severity
- CVSS Score: 7.5 / 10 (High)
- Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`

#### References
- [https://github.com/xmldom/xmldom/security/advisories/GHSA-wh4c-j3r5-mjhp](https://redirect.github.com/xmldom/xmldom/security/advisories/GHSA-wh4c-j3r5-mjhp)
- [https://github.com/xmldom/xmldom/commit/2b852e836ab86dbbd6cbaf0537f584dd0b5ac184](https://redirect.github.com/xmldom/xmldom/commit/2b852e836ab86dbbd6cbaf0537f584dd0b5ac184)
- [https://github.com/xmldom/xmldom/releases/tag/0.8.12](https://redirect.github.com/xmldom/xmldom/releases/tag/0.8.12)
- [https://github.com/xmldom/xmldom/releases/tag/0.9.9](https://redirect.github.com/xmldom/xmldom/releases/tag/0.9.9)
- [https://nvd.nist.gov/vuln/detail/CVE-2026-34601](https://nvd.nist.gov/vuln/detail/CVE-2026-34601)
- [https://github.com/advisories/GHSA-wh4c-j3r5-mjhp](https://redirect.github.com/advisories/GHSA-wh4c-j3r5-mjhp)

This data is provided by the [GitHub Advisory Database](https://redirect.github.com/advisories/GHSA-wh4c-j3r5-mjhp) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>

---

### xmldom has XML node injection through unvalidated processing instruction serialization
[CVE-2026-41675](https://nvd.nist.gov/vuln/detail/CVE-2026-41675) / [GHSA-x6wf-f3px-wcqx](https://redirect.github.com/advisories/GHSA-x6wf-f3px-wcqx)

<details>
<summary>More information</summary>

#### Details
##### 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):

case PROCESSING_INSTRUCTION_NODE:
    return buf.push('<?', node.target, ' ', node.data, '?>');

node.data is emitted verbatim. If it contains ?>, that sequence terminates the PI in the output
stream and the remainder appears as active XML markup.

Contrast — CDATA (line 2945, patched):

case CDATA_SECTION_NODE:
    return buf.push(g.CDATA_START, node.data.replace(/]]>/g, ']]]]><![CDATA[>'), g.CDATA_END);

PoC

Minimal (from @tlsbollei report, 2026-04-01)

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

const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(
    doc.createProcessingInstruction('a', '?><z/><?q ')
);
console.log(new XMLSerializer().serializeToString(doc));
// <r><?a ?><z/><?q ?></r>
//          ^^^^ injected <z/> element is active markup

With re-parse verification (from @tlsbollei report)

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

const doc = new DOMParser().parseFromString('<r/>', 'application/xml');
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));
const xml = new XMLSerializer().serializeToString(doc);
assert.strictEqual(new DOMParser().parseFromString(xml, 'application/xml')
    .getElementsByTagName('z').length, 1); // passes — z is a real element

Impact

An application that uses the package to build XML from untrusted input can be made to emit attacker-controlled elements outside the intended PI boundary. That allows the attacker to alter the meaning and structure of generated XML documents.

In practice, this can affect any workflow that generates XML and then stores it, forwards it, signs it, or hands it to another parser. Realistic targets include XML-based configuration, policy documents, and message formats where downstream consumers trust the serialized structure.

As noted by @tlsbollei: this is the same delimiter-driven XML injection bug class previously addressed by GHSA-wh4c-j3r5-mjhp for createCDATASection(). Fixing CDATA while leaving PI creation and PI serialization unguarded leaves the same standards-constrained issue open for another node type.

Disclosure

This vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via
xmldom/xmldom#987, which was subsequently closed
without being merged.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that pass
untrusted data 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:

Target check: throws InvalidStateError if the PI target contains a : character or is an ASCII case-insensitive match for "xml".
Data Char check: throws InvalidStateError if the PI data contains characters outside the XML Char production.
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

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

const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));

// Default (unchanged): verbatim — injection present
const unsafe = new XMLSerializer().serializeToString(doc);
console.log(unsafe);
// <r><?a ?><z/><?q ?></r>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The ProcessingInstruction data contains "?>"
}

The guard catches ?> regardless of when it was introduced:

// Post-creation mutation: also caught at serialization time
const pi = doc.createProcessingInstruction('target', 'safe data');
doc.documentElement.appendChild(pi);
pi.data = 'safe?><injected/>';
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
// InvalidStateError: The ProcessingInstruction data contains "?>"

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec §3.2.1.3 defines a require well-formed flag whose default value is false. With the flag unset, the spec explicitly permits serializing PI data verbatim. This matches browser behavior: Chrome, Firefox, and Safari all emit ?> in PI data verbatim by default without error.

Unconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in requireWellFormed: true flag allows applications that require injection safety to enable strict mode without breaking existing code.

Residual limitation

createProcessingInstruction(target, data) does not validate data at creation time. The WHATWG DOM spec (§4.5 step 2) mandates an InvalidCharacterError when data contains ?>; enforcing this check unconditionally at creation time is a breaking change and is deferred to a future breaking release.

When the default serialization path is used (without requireWellFormed: true), PI data containing ?> is still emitted verbatim. Applications that do not pass requireWellFormed: true remain exposed.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom has XML injection through unvalidated DocumentType serialization

CVE-2026-41674 / GHSA-f6ww-3ggp-fr8h

More information

Details

Summary

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 to createDocumentType() or write untrusted values directly to a
DocumentType node's publicId, systemId, or internalSubset properties 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 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 XML PubidLiteral production (XML 1.0 [12])
systemId: throws if non-empty and does not match the XML SystemLiteral production (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.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom: Uncontrolled recursion in XML serialization leads to DoS

CVE-2026-41673 / GHSA-2v35-w6hq-6mfw

More information

Details

Summary

Seven recursive traversals in lib/dom.js operate without a depth limit. A sufficiently deeply
nested DOM tree causes a RangeError: Maximum call stack size exceeded, crashing the application.

Reported operations:

Node.prototype.normalize() — reported by @praveen-kv (email 2026-04-05) and @KarimTantawey (GHSA-fwmp-8wwc-qhv6, via DOMParser.parseFromString())
XMLSerializer.serializeToString() — reported by @Jvr2022 (GHSA-2v35-w6hq-6mfw) and @KarimTantawey (GHSA-j2hf-fqwf-rrjf)

Additionally, discovered in research:

Element.getElementsByTagName() / getElementsByTagNameNS() / getElementsByClassName() / getElementById()
Node.cloneNode(true)
Document.importNode(node, true)
node.textContent (getter)
Node.isEqualNode(other)

All seven share the same root cause: pure-JavaScript recursive tree traversal with no depth guard.
A single deeply nested document (parsed successfully) triggers any or all of these operations.

Details

Root cause

lib/dom.js implements DOM tree traversals as depth-first recursive functions. Each level of
element nesting adds one JavaScript call frame. The JS engine's call stack is finite; once
exhausted, a RangeError: Maximum call stack size exceeded is thrown. This error may not be
caught reliably at stack-exhaustion depths because the catch handler itself requires stack
frames to execute — especially in async scenarios, where an uncaught RangeError inside a
callback or promise chain can crash the entire Node.js process.

Parsing a deeply nested document succeeds — the SAX parser in lib/sax.js is iterative.
The crash occurs during subsequent operations on the parsed DOM.

`Node.prototype.normalize()` — reported by @praveen-kv

lib/dom.js:1296–1308 (main):

normalize: function () {
    var child = this.firstChild;
    while (child) {
        var next = child.nextSibling;
        if (next && next.nodeType == TEXT_NODE && child.nodeType == TEXT_NODE) {
            this.removeChild(next);
            child.appendData(next.data);
        } else {
            child.normalize();   // recursive call — no depth guard
            child = next;
        }
    }
},

Crash threshold (Node.js 18, default stack): ~10,000 levels.

`XMLSerializer.serializeToString()` — reported by @Jvr2022

lib/dom.js:2790–2974 (main):
The internal serializeToString worker recurses into child nodes at four call sites, each
passing a visibleNamespaces.slice() copy. The per-frame allocation causes earlier stack
exhaustion than normalize().

Crash threshold (Node.js 18, default stack): ~5,000 levels.

Additional recursive entry points

All five crash at ~10,000 levels on Node.js 18.

Function	Definition	Public API entry point(s)	Crash depth (Node.js 18)
`_visitNode`	`lib/dom.js:1529`	`getElementsByTagName()`, `getElementsByTagNameNS()`, `getElementsByClassName()`, `getElementById()`	~10,000 levels
`cloneNode` (module fn)	`lib/dom.js:3037`	`Node.prototype.cloneNode(true)`	~10,000 levels
`importNode` (module fn)	`lib/dom.js:2975`	`Document.prototype.importNode(node, true)`	~10,000 levels
`getTextContent` (inner fn)	`lib/dom.js:3130`	`node.textContent` (getter)	~10,000 levels
`isEqualNode`	`lib/dom.js:1120`	`Node.prototype.isEqualNode(other)`	~10,000 levels

Both active branches (main and release-0.8.x) are identically affected. The unscoped xmldom
package (≤ 0.6.0) carries the same recursive patterns from its initial commit.

Browser behavior

Tested with Chromium 147 (Playwright headless). Chromium's native C++ implementations of all
seven DOM methods are iterative — they traverse the DOM without consuming JS call stack frames.
All seven succeed at depths up to 20,000 without any crash.

When @xmldom/xmldom is bundled and run in a browser context the same recursive JS code executes
under the browser's V8 stack limit (~12,000–13,000 frames). The crash thresholds are similar to
those observed on Node.js 18 (~5,000 for serializeToString, ~10,000 for the remaining six).

The vulnerability is specific to xmldom's pure-JavaScript recursive implementation, not an
inherent property of the DOM operations.

PoC

`normalize()` (from @praveen-kv report, 2026-04-05)

const { DOMParser } = require('@xmldom/xmldom');

function generateNestedXML(depth) {
    return '<root>' + '<a>'.repeat(depth) + 'text' + '</a>'.repeat(depth) + '</root>';
}

const doc = new DOMParser().parseFromString(generateNestedXML(10000), 'text/xml');
doc.documentElement.normalize();
// RangeError: Maximum call stack size exceeded

`XMLSerializer.serializeToString()` (from GHSA-2v35-w6hq-6mfw)

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

const depth = 5000;
const xml = '<a>'.repeat(depth) + '</a>'.repeat(depth);
const doc = new DOMParser().parseFromString(xml, 'text/xml');
new XMLSerializer().serializeToString(doc);
// RangeError: Maximum call stack size exceeded

The other methods have been verified using similar pocs.

Impact

Any service that accepts attacker-controlled XML and subsequently calls any of the seven affected
DOM operations can be forced into a reliable denial of service with a single crafted payload.

The immediate result is an uncaught RangeError and failed request processing. In deployments
where uncaught exceptions terminate the worker or process, the impact can extend beyond a single
request and disrupt service availability more broadly.

No authentication, special options, or invalid XML is required. A valid, deeply nested XML
document is enough.

Disclosure

The normalize() vector was publicly disclosed at 2026-04-06T11:25:07Z via
xmldom/xmldom#987 (closed without merge).
serializeToString() and the five additional recursive entry points were not mentioned in that PR.

Fix Applied

All seven affected traversals have been converted from recursive to iterative implementations, eliminating call-stack consumption on deep trees.

`walkDOM` utility

A new walkDOM(node, context, callbacks) utility is introduced. It traverses the subtree rooted at node in depth-first order using an explicit JavaScript array as a stack, consuming heap memory instead of call-stack frames. context is an arbitrary value threaded through the walk — each callbacks.enter(node, context) call returns the context to pass to that node's children, enabling per-branch state (e.g. namespace snapshots in the serializer). callbacks.exit(node, context) (optional) is called in post-order after all children have been visited.

The following six operations are re-implemented on top of walkDOM:

Operation	Public entry point(s)
`_visitNode` helper	`getElementsByTagName()`, `getElementsByTagNameNS()`, `getElementsByClassName()`, `getElementById()`
`getTextContent` inner function	`node.textContent` getter
`cloneNode` module function	`Node.prototype.cloneNode(true)`
`importNode` module function	`Document.prototype.importNode(node, true)`
`serializeToString` worker	`XMLSerializer.prototype.serializeToString()`, `Node.prototype.toString()`, `NodeList.prototype.toString()`
`normalize`	`Node.prototype.normalize()`

normalize uses walkDOM with a null context and an enter callback that merges adjacent Text children of the current node before walkDOM reads and queues those children — so the surviving post-merge children are what the walker descends into.

Custom iterative loop for `isEqualNode`

One function cannot use walkDOM:

Node.prototype.isEqualNode(other) (0.9.x only; absent from 0.8.x) compares two trees in parallel. It maintains an explicit stack of {node, other} node pairs — one node from each tree — which cannot be expressed with walkDOM's single-tree visitor.

After the fix

All seven entry points succeed on trees of arbitrary depth without throwing RangeError. The original PoCs still demonstrate the vulnerability on unpatched versions and confirm the fix on patched versions.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom has XML node injection through unvalidated comment serialization

CVE-2026-41672 / GHSA-j759-j44w-7fr8

More information

Details

Summary

The package allows attacker-controlled comment content to be serialized into XML without validating or neutralizing comment breaking sequences. As a result, an attacker can terminate the comment early and inject arbitrary XML nodes into the serialized output.

Details

The issue is in the DOM construction and serialization flow for comment nodes.

When createComment(data) is called, the supplied string is stored as comment data through the generic character-data handling path. That content is kept as-is. Later, when the document is serialized, the serializer writes comment nodes by concatenating the XML comment delimiters with the stored node.data value directly.

That behavior is unsafe because XML comments are a syntax-sensitive context. If attacker-controlled input contains a sequence that closes the comment, the serializer does not preserve it as literal comment text. Instead, it emits output where the remainder of the payload is treated as live XML markup.

This is a real injection bug, not a formatting issue. The serializer already applies context-aware handling in other places, such as escaping text nodes and rewriting unsafe CDATA terminators. Comment content does not receive equivalent treatment. Because of that gap, untrusted data can break out of the comment boundary and modify the structure of the final XML document.

PoC

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

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

doc.documentElement.appendChild(
  doc.createComment('--><injected attr="1"/><!--')
);

const xml = new XMLSerializer().serializeToString(doc);
console.log(xml);
// <root><!----><injected attr="1"/><!----></root>

const reparsed = new DOMParser().parseFromString(xml, 'text/xml');
console.log(reparsed.documentElement.childNodes.item(1).nodeName);
// injected

Impact

An application that uses the package to build XML from untrusted input can be made to emit attacker-controlled elements outside the intended comment 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.

Disclosure

This vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via xmldom/xmldom#987, which was subsequently closed without being merged.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that pass
untrusted data to createComment() or mutate comment nodes with untrusted input (via
appendData, insertData, replaceData, .data =, or .textContent =) 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 a Comment node whose .data would produce malformed XML.

On @xmldom/xmldom ≥ 0.9.10, the full W3C DOM Parsing §3.2.1.4 check is applied: throws if .data contains -- anywhere, ends with -, or contains characters outside the XML Char production.

On @xmldom/xmldom ≥ 0.8.13 (LTS), only the --> injection sequence is checked. The 0.8.x SAX parser accepts comments containing -- (without >), so throwing on bare -- would break a previously-working round-trip on that branch. The --> check is sufficient to prevent injection.

PoC — fixed path

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

const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.appendChild(doc.createComment('--><injected attr="1"/><!--'));

// Default (unchanged): verbatim — injection present
const unsafe = new XMLSerializer().serializeToString(doc);
console.log(unsafe);
// <root><!----><injected attr="1"/><!----></root>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The comment node data contains "--" or ends with "-"  (0.9.x)
  // InvalidStateError: The comment node data contains "-->"  (0.8.x — only --> is checked)
}

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec §3.2.1.4 defines a require well-formed flag whose default value is false. With the flag unset, the spec explicitly permits serializing ill-formed comment content verbatim — this is also the behavior of browser implementations (Chrome, Firefox, Safari): new XMLSerializer().serializeToString(doc) produces the injection sequence without error in all major browsers.

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

The fix operates at serialization time only. There is no creation-time check in createComment — the spec does not require one for comment data. Any path that leads to a Comment node with -- in its data (createComment, appendData, .data =, etc.) produces a node that serializes safely only when { requireWellFormed: true } is passed to serializeToString.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization

CVE-2026-83610 / GHSA-6gmq-8vp8-gcm6

More information

Details

Summary

An EntityReference node can be created with an invalid, attacker-controlled name through Document.createEntityReference(name). When this node is serialized directly with:

serializer.serializeToString(ref, { requireWellFormed: true })

the invalid nodeName is emitted into the serialized XML fragment without validation or escaping.

This can produce real XML markup in the serialized output. In the proof of concept below, the serialized fragment contains <injected/>, and reparsing the fragment creates a real injected element.

Details

The issue appears to be in the serialization path for ENTITY_REFERENCE_NODE.

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

However, for ENTITY_REFERENCE_NODE, the serializer appears to emit the node name directly in entity reference form:

case ENTITY_REFERENCE_NODE:
  buf.push('&', n.nodeName, ';');
  return null;

As a result, if nodeName contains characters that break out of the intended &name; structure, the serializer can emit additional XML markup.

For example, an entity reference created with the name:

safe; <injected/> &x

is serialized as:

&safe; <injected/> &x;

When this fragment is later parsed in an XML context, <injected/> becomes a real element.

This is especially surprising when { requireWellFormed: true } is used, because applications may reasonably treat this mode as the stricter or safer XML serialization mode.

Proof of Concept

Tested with:

@xmldom/xmldom@0.9.10
Node.js v24.18.0
Windows 10 / PowerShell

'use strict';

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

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

function countInjected(fragment) {
  try {
    const parsed = new DOMParser().parseFromString(`<root>${fragment}</root>`, 'application/xml');
    return parsed.getElementsByTagName('injected').length;
  } catch (e) {
    return `PARSE_THROW ${e.name}: ${e.message}`;
  }
}

for (const name of [
  'safe',
  'safe; <injected/> &x',
  'x<injected',
  'x y'
]) {
  try {
    const ref = doc.createEntityReference(name);
    const xml = serializer.serializeToString(ref, { requireWellFormed: true });

    console.log(`[SERIALIZED] ${JSON.stringify(name)}: ${xml}`);
    console.log(`[INJECTED_COUNT] ${JSON.stringify(name)}: ${countInjected(xml)}`);
  } catch (e) {
    console.log(`[THROW] ${JSON.stringify(name)}: ${e.name}: ${e.message}`);
  }
}

Observed output:

[SERIALIZED] "safe": &safe;
[INJECTED_COUNT] "safe": 0

[SERIALIZED] "safe; <injected/> &x": &safe; <injected/> &x;
[INJECTED_COUNT] "safe; <injected/> &x": 1

[SERIALIZED] "x<injected": &x<injected;
[INJECTED_COUNT] "x<injected": 0

[SERIALIZED] "x y": &x y;
[INJECTED_COUNT] "x y": 0

Impact

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

The impact is limited by two observations:

The parser does not create EntityReference nodes from ordinary XML entity references.
Appending an EntityReference node as an element child is rejected with a HierarchyRequestError.

The main affected scenario is applications that directly use createEntityReference(name) and then serialize the resulting node or fragment.

Fix Applied

Two complementary, non-breaking fixes.
(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.
(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 &name;. 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.

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

Proof of Concept - fixed path

'use strict';

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

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

// Creation-time anchor (applied by default): an invalid XML Name is rejected at creation.
try {
  doc.createEntityReference('safe; <injected/> &x');
} catch (e) {
  console.log(`${e.name}`); // rejected at creation
}

// Default path (requireWellFormed omitted): because creation now rejects an ill-formed name,
// an ill-formed nodeName is only reachable via a post-creation mutation — and is emitted verbatim.
const ref = doc.createEntityReference('safe');
ref.nodeName = 'safe; <injected/> &x';
console.log(serializer.serializeToString(ref));
// -> &safe; <injected/> &x;   (injection present on the default path)

// Opt-in path: throws on the invalid nodeName.
try {
  serializer.serializeToString(ref, { requireWellFormed: true });
} catch (e) {
  console.log(`${e.name}`); // InvalidStateError
}

// A valid name still serializes as &name; under requireWellFormed.
const ok = doc.createEntityReference('valid');
console.log(serializer.serializeToString(ok, { requireWellFormed: true }));
// -> &valid;

Why the default stays verbatim

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

Residual limitation

The 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 }.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: 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

References

https://github.com/xmldom/xmldom/security/advisories/GHSA-6gmq-8vp8-gcm6
https://nvd.nist.gov/vuln/detail/CVE-2026-83610
https://github.com/xmldom/xmldom/pull/1071
https://github.com/xmldom/xmldom/pull/1072
[https://github.com/xmldom/xmldom/commit/4664386e4f4d99d17b416a151dbe8323e245284b

❗ Important

✂ PR body was truncated to here.

renovate · 2026-09-02T15:55:49Z

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json

npm warn Unknown env config "store". This will error in a future major version of npm. See `npm help npmrc` for supported config options.
npm error code EBADENGINE
npm error engine Unsupported engine
npm error engine Not compatible with your version of node/npm: @adobe/mysticat-shared-seo-client@1.8.0
npm error notsup Not compatible with your version of node/npm: @adobe/mysticat-shared-seo-client@1.8.0
npm error notsup Required: {"node":">=22.0.0 <25.0.0","npm":">=10.9.0 <12.0.0"}
npm error notsup Actual:   {"node":"v24.15.0","npm":"12.0.2"}
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-09-11T13_03_14_274Z-debug-0.log

github-actions · 2026-09-02T15:55:51Z

This PR will trigger no release when merged.

renovate Bot enabled auto-merge (squash) September 2, 2026 15:55

renovate Bot force-pushed the renovate-npm-xmldom-xmldom-vulnerability branch 27 times, most recently from 8fd2c0a to 2ac39f8 Compare September 4, 2026 13:59

renovate Bot force-pushed the renovate-npm-xmldom-xmldom-vulnerability branch 29 times, most recently from e371401 to ddc14f0 Compare September 9, 2026 11:30

chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security]

a7810e6

Navigation Menu

Uh oh!

chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security] - #3185

chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security]#3185
renovate[bot] wants to merge 1 commit into
mainfrom
renovate-npm-xmldom-xmldom-vulnerability

renovate Bot commented Sep 2, 2026 •

edited

Loading

Uh oh!

renovate Bot commented Sep 2, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

renovate Bot commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

xmldom: XML injection via unsafe CDATA serialization allows attacker-controlled markup insertion

Details

Summary

Attack surface

Parse path

Impact

Root Cause (with file + line numbers)

1. No validation in createCDATASection

2. Unsafe CDATA serialization

Proof of Concept — Fix A: createCDATASection now throws

Proof of Concept — Fix B: mutation vector now safe

Fix Applied

Option A — Strict/spec-aligned: reject ]]> in createCDATASection()

Option B — Defensive serialization: split the terminator during serialization

Update — 2026-04-xx (0.9.10 / 0.8.13)

splitCDATASections is deprecated

Migration

PoC

Minimal (from @​tlsbollei report, 2026-04-01)

With re-parse verification (from @​tlsbollei report)

Impact

Disclosure

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

References

xmldom has XML injection through unvalidated DocumentType serialization

Details

Summary

Details

Affected code

PoC

internalSubset injection

publicId quoting context break

systemId injection

Impact

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

References

xmldom: Uncontrolled recursion in XML serialization leads to DoS

Details

Summary

Details

Root cause

Node.prototype.normalize() — reported by @​praveen-kv

XMLSerializer.serializeToString() — reported by @​Jvr2022

Additional recursive entry points

Browser behavior

PoC

normalize() (from @​praveen-kv report, 2026-04-05)

XMLSerializer.serializeToString() (from GHSA-2v35-w6hq-6mfw)

Impact

Disclosure

Fix Applied

walkDOM utility

Custom iterative loop for isEqualNode

After the fix

Severity

References

xmldom has XML node injection through unvalidated comment serialization

Details

Summary

Details

PoC

Impact

Disclosure

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

renovate Bot commented Sep 2, 2026 •

edited

Loading

1. No validation in `createCDATASection`

Proof of Concept — Fix A: `createCDATASection` now throws

Option A — Strict/spec-aligned: reject `]]>` in `createCDATASection()`

`splitCDATASections` is deprecated

Minimal (from @tlsbollei report, 2026-04-01)

With re-parse verification (from @tlsbollei report)

`Node.prototype.normalize()` — reported by @praveen-kv

`XMLSerializer.serializeToString()` — reported by @Jvr2022

`normalize()` (from @praveen-kv report, 2026-04-05)

`XMLSerializer.serializeToString()` (from GHSA-2v35-w6hq-6mfw)

`walkDOM` utility

Custom iterative loop for `isEqualNode`

renovate Bot commented Sep 2, 2026 •

edited

Loading