Skip to content

Incompatibility with @xmldom/xmldom 0.9.x: DOMParser.parseFromString throws on undefined mimeType #115

@esetnik

Description

@esetnik

Summary

saml@4.0.0 declares "@xmldom/xmldom": "^0.7.4" (package.json). @xmldom/xmldom@0.9.0 introduced a breaking change to DOMParser.parseFromString() — the mimeType argument is now required and an undefined value throws. Because latest on the npm registry now points at 0.9.10 (LTS is still 0.8.10), any consumer that uses an SCA tool / Renovate / Dependabot to widen the xmldom range past the existing 0.7.x CVE floor (CVE-2026-34601) lands on 0.9.x and breaks at runtime.

Repro

lib/utils.js:72 calls parseFromString with one argument:

```js
factoryForNode: function(xmlString) {
var doc = new DOMParser().parseFromString(xmlString);
// ...
}
```

Under @xmldom/xmldom@0.9.x:

```
TypeError: DOMParser.parseFromString: the provided mimeType "undefined" is not valid.
at DOMParser.parseFromString (.../@xmldom/xmldom/lib/dom-parser.js:222:9)
at Object.factoryForNode (.../saml/lib/utils.js:72:37)
at Object. (.../saml/lib/saml11.js:12:31)
```

Why this matters now

  • The ^0.7.4 range made sense at the time of saml@4.0.0, but 0.7.x has CVE-2026-34601 (XML injection via unsafe CDATA serialization). Downstream consumers cannot stay on 0.7.x without violating their security policies, so they end up either pinning manually or using package-manager overrides — both of which are fragile.
  • There are two existing PRs that would address this — #76 (2021) and #101 (Snyk, 2024) — but both have sat untouched. [Snyk] Upgrade @xmldom/xmldom from 0.7.13 to 0.8.10 #101 is mergeable with 0 comments after ~2 years.

Suggested fix

Bump @xmldom/xmldom to either:

  1. ^0.8.10 — matches current LTS, no API changes required (this is what [Snyk] Upgrade @xmldom/xmldom from 0.7.13 to 0.8.10 #101 proposes).
  2. ^0.9.10 — matches current latest, requires updating factoryForNode (and any other call site) to pass an explicit mimeType ('text/xml' or 'application/xml').

Option 1 is the minimum safe bump and gets users out of the CVE floor; option 2 is the forward-looking fix.

Happy to send a PR if it would help unblock #101.


Reported during a transitive-dep regression on a downstream project. Filing here as a paper trail since neither prior PR mentions the 0.9.x compat break specifically.

[Written by Claude]

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions