chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security] - #1152
Open
renovate[bot] wants to merge 1 commit into
Open
chore(deps): update dependency @xmldom/xmldom to v0.9.12 [security]#1152renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1152 +/- ##
==========================================
- Coverage 63.91% 63.83% -0.09%
==========================================
Files 19 19
Lines 2425 2425
Branches 575 575
==========================================
- Hits 1550 1548 -2
- Misses 875 877 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.9.10→0.9.12xmldom: XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization
CVE-2026-83610 / GHSA-6gmq-8vp8-gcm6
More information
Details
Summary
An
EntityReferencenode can be created with an invalid, attacker-controlled name throughDocument.createEntityReference(name). When this node is serialized directly with:the invalid
nodeNameis 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 realinjectedelement.Details
The issue appears to be in the serialization path for
ENTITY_REFERENCE_NODE.For several other node types,
requireWellFormed: trueperforms 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:As a result, if
nodeNamecontains 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:
is serialized as:
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:
Observed output:
Impact
An application that creates an
EntityReferencefrom attacker-controlled input and then serializes that node or XML fragment withrequireWellFormed: truemay produce XML containing attacker-controlled markup.The impact is limited by two observations:
EntityReferencenodes from ordinary XML entity references.EntityReferencenode as an element child is rejected with aHierarchyRequestError.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 invalidNameat creation, closing the reachable creation vector by default — the opt-in serializer check alone cannot, since a laternodeNamemutation would bypass a creation-only guard.(2) Under
requireWellFormed, the serializer validates theEntityReferencenodeNameas a well-formed XMLNameand throwsInvalidStateErrorwhen it is not; a valid reference still serializes as&name;. Both ship on both maintained versions. TheEntityReference/createEntityReferencedocs note that underrequireWellFormedthenodeNameis validated as an XMLName, and that xmldom does not expand entities. See the XMLNameproduction.Proof of Concept - fixed path
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 tofalse, and the browserXMLSerializeremits thenodeNameverbatim in that default mode, so unconditionally throwing for an ill-formedEntityReference.nodeNamewould 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
nodeNameverbatim, because the serializer check is opt-in via{ requireWellFormed: true }.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
xmldom/xmldom (@xmldom/xmldom)
v0.9.12Compare Source
Fixed
DOMParser.parseFromStringwith default options. Serialized output is byte-identical.GHSA-965w-775f-mr7gNamedNodeMapparse-time dedup path uses a null-prototype membership index, so a well-formed document with a hostile number of duplicate attributes can no longer wedge the parse. Attribute order and duplicate resolution (last value wins, first position kept) are byte-identical, preserving the XML no-duplicate-attributes well-formedness constraint.GHSA-8344-3jmq-59r6GHSA-6mj3-qw4j-hgrw<, andNode.prototype.normalize()merges adjacent text nodes in O(K) instead of O(K²) (also reachable programmatically), pernormalize()in the WHATWG DOM spec. DOM output is unchanged; only the reported error text differs.GHSA-93r5-fhx6-vmg9XMLSerializer.serializeToString()under{ requireWellFormed: true }now rejects a DocTypenamethat is not a valid XMLName, throwingInvalidStateError— matching the siblingpublicId/systemId/internalSubsetchecks and preventing XML injection viaDocumentType.name.GHSA-27p8-2357-5qqvXMLSerializer.serializeToString()under{ requireWellFormed: true }now validates a processing-instruction target as an XMLNCNameand rejects a case-insensitivexml, throwingInvalidStateError— preventing PI-target injection via>,?, or whitespace.GHSA-c7q8-3ch8-vqpvDocument.createEntityReference()now rejects an invalid XMLNameat creation, andXMLSerializer.serializeToString()under{ requireWellFormed: true }validates anEntityReferencenodeNameas an XMLName, throwingInvalidStateError— preventing XML injection via an entity-reference name.GHSA-6gmq-8vp8-gcm6requireWellFormedserializer's element- and attribute-name validators no longer treat an interior line terminator as satisfying the name anchors, so a name containing a line terminator is rejected withInvalidStateError— closing a bypass of the XMLQNamecheck.GHSA-jxjr-3g7g-3944requireWellFormedserializer's DocTypepublicId/systemIdvalidators no longer treat an interior line terminator as satisfying the anchor, so an identifier containing an ECMAScript line terminator is rejected withInvalidStateError— closing a bypass of the XMLPubidLiteral/SystemLiteralcheck.GHSA-vr34-hp96-76ppcreateElementNS(),createAttributeNS(),createDocumentType(), andcreateAttribute()now reject a name containing a line terminator withInvalidCharacterError, because name validation applies to the whole string — closing a creation-time bypass of the XMLName/QNameproduction on the default serialization path.GHSA-3px3-54cx-rmw9errorin XML, awarningin HTML) instead of accepting it silently, per the XMLETagproduction; parsing recovers to the byte-identical DOM. Consumers that want strict rejection can escalate the reportederrorto fatal via the parser'sonErrorhandler.GHSA-6h8r-xr42-gp59DOMExceptions raised during parsing are now reported as afatalError, and the originating error is preserved as thecauseon the resultingParseError.Chore
Thank you,
@ericchiang,
@KarimTantawey,
@bhaswanthc,
@arpitjain099,
@Paranoidgrinch,
for your contributions
v0.9.11Compare Source
Fixed
XMLSerializer.serializeToString()now also rejects invalid element and attribute names when{ requireWellFormed: true }is passed, throwingInvalidStateErrorfor a name that is not a valid XMLQName(this covers the namespace prefix, which surfaces in the element qualified name or in a synthesizedxmlns:declaration). This prevents XML injection viacreateElement()/setAttribute(), extending the existingrequireWellFormedchecks to the serialized name set.GHSA-w2rr-34g9-rvrjGHSA-4w3w-2rp5-g8jm<?…with no closing?>), preventing a denial-of-service (ReDoS) reachable fromDOMParser.parseFromStringwith default options.GHSA-g53g-w8rj-fmg7CharacterDatanodeValueanddataare now kept in sync#990Chore
Thank you,
@bhaswanthc,
@jmestwa-coder,
@stevenobiajulu,
for your contributions
Configuration
📅 Schedule: (in timezone Europe/Berlin)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.