Backstory
node-saml traces its lineage to passport-saml, a SAML 2.0 authentication plugin written for the Passport framework. When contributors consolidated the project, they created the node-saml GitHub organization in June 2020, and later split the framework-agnostic SAML core into its own package, publishing the first scoped @node-saml/node-saml release to npm on June 25, 2022. passport-saml was rescoped to @node-saml/passport-saml and now depends on node-saml for the actual SAML processing. For XML parsing and signature verification, node-saml relies on the xml-crypto library.
CVE-2025-54419 is an XML Signature Wrapping bypass, published July 28, 2025 and rated CVSS 10.0. The root cause is a divergence between what node-saml cryptographically verified and what it then read. After confirming a signature was valid, the library extracted assertion data from the original, unsigned response document rather than from the specific content the signature actually covered. An attacker holding one validly signed assertion from an identity provider could restructure the surrounding XML so the signature still verified against the legitimate element while node-saml consumed attacker-modified authentication details, including changes to the username.
This is a recurring bug class in SAML tooling. In 2012, Somorovsky and colleagues published "On Breaking SAML: Be Whoever You Want to Be," demonstrating XSW against 11 of 14 tested frameworks. CVE-2017-11427 hit OneLogin's python3-saml through incorrect DOM traversal and canonicalization. In March 2025 the pattern resurfaced across the ecosystem: ruby-saml (CVE-2025-25291 and CVE-2025-25292) was broken by a parser differential between REXML and Nokogiri, and node-saml's own dependency xml-crypto (CVE-2025-29774 and CVE-2025-29775) allowed signatures to verify over content that was not what got processed. node-saml had earlier shipped CVE-2021-39171, a signed-node transform issue in passport-saml.
The maintainers fixed CVE-2025-54419 in node-saml 5.1.0, released July 21, 2025, a week ahead of the public advisory. The fix (PR #397, commit 31ead94) adopts xml-crypto's newer signedReferences interface, replacing boolean signature checks with a getVerifiedXml call so the library reads assertions from the verified content itself. The commit message states the goal directly: use the new signedReferences interface in xml-crypto to "see what is signed."
Technical analysis (revisited)
The attack primitive is XML Signature Wrapping, and the flaw is structural rather than cryptographic. The signature math was never broken. node-saml validated the digital signature over a legitimately signed assertion, then extracted the identity it acted on from a separate, unsigned part of the document. An attacker who already possessed one validly signed SAML response (obtained by intercepting a real login flow, or by holding their own valid low-privilege credentials) could wrap it: keep the signed element in place to satisfy the signature check, then inject or modify an unsigned assertion carrying a different username. The verify step passed; the read step consumed the forgery.
Post-disclosure analyses converge on this mechanism. ZeroPath described the flaw as assertion data being extracted from the original unsigned XML rather than the cryptographically validated content, so authentication attributes could be altered without invalidating the signature. Wiz cataloged the package at roughly 258,000 weekly downloads, the reason a single library bug carries broad enterprise SSO exposure.
The disclosure sits inside a cluster. The researcher credited on the node-saml advisory, "ahacker1," also reported the earlier xml-crypto bugs marketed as "SAMLStorm" (CVE-2025-29774 and CVE-2025-29775). Those are distinct CVEs in the underlying signature library, not this one, but they are the same signature-wrapping family and the same reporter, and they landed months apart in 2025. The 5.1.0 fix is an architectural change, not a spot patch: before it, node-saml called a boolean signature validator and then separately located the assertion in the response document. After it, the assertion is read from xml-crypto's verified references, closing the gap between the two operations.
Lifecycle timeline
Real-world outcome
Twelve months after disclosure, no public exploitation of CVE-2025-54419 has surfaced. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no security firm has reported in-the-wild abuse. ZeroPath, Wiz, and NVD all describe it by severity rather than by observed attacks. The original CVE Brief analyst note, dated July 28, 2025, recorded no known public exploitation at the time; that assessment still holds as of July 2026.
The remediation timeline is part of why. The fix shipped in node-saml 5.1.0 on July 21, 2025, a week before the coordinated GHSA and NVD publication on July 28. Defenders who tracked node-saml releases could update before the CVE was public. Because node-saml is a dependency pulled in through the npm tree rather than an appliance an operator installs directly, exposure is a function of how quickly downstream applications bumped a transitive dependency, which is not publicly measurable at the ecosystem scale. What is measurable is that a CVSS 10 authentication bypass in a library with roughly a quarter-million weekly downloads has, so far, produced no attributed incident.
Lessons
This case shows that a signature check is only meaningful if the bytes verified are the bytes consumed. The signature over the legitimate assertion was valid throughout; the bypass lived in the gap between verifying one part of the document and reading another. XML Signature Wrapping keeps recurring across languages, from python3-saml in 2017 to ruby-saml and xml-crypto in early 2025, because the verify step and the extract step are usually separate code paths, and any structure that lets them disagree is exploitable. The node-saml fix is instructive on that point: it did not add another check, it removed the divergence, reading identity from the verified references returned by the signature layer rather than re-locating it in the raw document. The pattern here is that hardening a SAML consumer against wrapping is less about detecting malformed responses and more about ensuring a single source of truth for what was actually signed.
References