Authentication bypass vulnerabilities in node-saml

Table of contents

1. Overview
2. Timeline
3. Problem
4. Remediation
5. Conclusion

Overview

TLDR;

• Stytch customers are safe and not impacted
• Stytch customers and end users were protected against these vulnerabilities prior to public disclosure
• Stytch reviewed internal logs and has not identified any indicators of compromise; Stytch continues to monitor the situation
• Stytch services did not experience any downtime nor degraded service

On March 4th, 2025, the Stytch team was made aware of an authentication bypass vulnerability in the node-saml library. The exploit is possible because of improper validation in the xml-crypto library, used by node-saml for verifying signatures. A missing validation check enabled a signature wrap attack to forge an SAML assertion to enable login as an arbitrary user. A second authentication bypass vulnerability was later identified, also in the xml-crypto library, that allowed for multiple SignedInfo nodes to be parsed for any SignatureValue block.

Timeline

All times in the postmortem are in PT.

3/4/25

• 9:43 PM - Security researcher contacts security@stytch.com with the reported vulnerability
• 9:58 PM - Initial triage of the issue occurs and the team starts work on verifying the report and reproducibility

3/5/25

• 3:05 AM - Legitimacy of vulnerability is confirmed; investigation to Stytch’s specific use case and other mitigating factors continued
• 7:59 AM - Confirmed reproducibility with node-saml v4.0.5, the version of the library running in production at Stytch
• 11:06 AM - The team identifies two viable options for patching (see remediation for more details)
• 11:47 AM - Additional logging is deployed to identify potential exploits and safety of deploying one of the patching options
• 12:56 PM - Decision is made on which patch to move forward with
• 2:08 PM - Patch is deployed to production; Stytch continues monitoring service activity

3/13/25

• 5:11 PM - We were made aware of an additional authentication bypass vulnerability with multiple SignedInfo nodes
• 7:58 PM - Patch to block any SAML requests with multiple SignedInfo nodes is deployed to production. In parallel we investigate to confirm that this vulnerability has not been exploited

Problem

The node-saml library relies on the xml-crypto library for XML signature verification in SAML responses. Due to improper cryptographic verification, comments can be arbitrarily contained in the XML payload used for SAML assertion.

In the node-saml library, the following process occurs:

1. The xml-crypto library is used to load the SignatureValue block into separate classes such as SignedInfo
2. The node-saml library verification process happens but does not correctly verify the SignatureValue block
   1. This signature verification process starts with the signer verifying the SignedInfo block is properly signed, but during the process a canonicalized version is created where the comments are stripped from the SignedInfo block, allowing for an attacker to put arbitrary data in the comments that don’t impact the signature
   2. The SignedInfo block contains a DigestValue block that the verifier uses to compute the digest of the SAML assertion. This is designed to prevent an attacker from modifying the assertion
   3. However, the xml-crypto library wasn’t using the canonicalized version of the SignedInfo block when extracting the digest to compare the signature against and so could be influenced by the presence of comments
3. In the node-saml library, the firstChild method is called on nodes[0] to get the DigestValue
4. The DigestValue block is internally parsed as a sequence of nodes in the xml-crypto library meaning calling firstChild on the DigestValue block will return the comments, which can contain arbitrary data from an attacker
5. This arbitrary data then becomes the actual DigestValue that xml-crypto uses during verification. Since xml-crypto compares this attacker-provided DigestValue against the canonicalized digest of the modified (attacker-controlled) assertion, the verification incorrectly passes
   1. In order for the attacker to create the right payload, they simply need a valid DigestValue and SignatureValue pair, this can be obtained from any XML document that has been signed by the IdP to create a properly signed XML payload to create a forged SAML assertion. The key pieces needed to create a SAML assertion for an arbitrary user are:
      1. Service provider data: NameID, ACS, and EntityID
      2. Username of the victim account
      3. Consequently, the attacker successfully authenticates as any arbitrary user

Multiple SignedInfo nodes

The xml-crypto library allowed for multiple SignedInfo nodes to be passed within the SignatureValue block. This means that an attacker can pass an additional SignedInfo node containing arbitrary data.

The validation works by applying the SignatureValue to the DigestValue not the whole document. So an attacker can:

1. Take a valid XML payload and its SignatureValue and DigestValue and inject that into another, malicious payload
2. When the XML payload is parsed and verified, one parser pass validates that the malicious DigestValue matches the malicious payload and a second parser pass validates that the good DigestValue matches the SignatureValue
3. The malicious payload is then trusted because both verifications passed

Remediation

The comment wrapping attack works via smuggling comments in the SignedInfo node, so to patch this there are a couple options.

1. Strip all comments from the XML
2. Fail any request with comments in the XML

Both are viable solutions to prevent this attack. Stytch implemented the second option out of an abundance of caution. We verified that legitimate requests do not contain, and should never contain, comments. Therefore taking this approach was the most thorough remediation, would not impact real traffic, as well as protecting Stytch and Stytch users from this entire class of attacks.

The multiple SignedInfo nodes attack works because there is no validation on those nodes and their legitimacy. Since there is no legitimate reason for multiple SignedInfo nodes, a viable solution is to block any XML payloads that contain more than one SignedInfo per SignatureValue block. We implemented checks to ensure that exactly one SignedInfo node is present per SignatureValue block.

Conclusion

We engaged an independent third party to assist in completing an analysis to identify if this had been exploited on our systems and were able to conclude with a high degree of confidence that it has not. We’ve added additional monitoring and alerting to ensure any attempts at an exploit will be immediately identified (though the response will fail as the implemented changes are designed to do). In addition to updating to the patched version of xml-crypto, we’ve also introduced a number of hardening features to preventatively protect against variants of this attack.

As of 3/14/25, CVEs for both vulnerabilities, XML Signature Verification Bypass via DigestValue Comment and XML Signature Verification Bypass via Multiple SignedInfo References, and a patched version of xml-crypto have been released. We’d like to thank Alexander Tan for the responsible disclosure of these vulnerabilities.

If you have any questions or concerns regarding this vulnerability or Stytch's security practices, please do not hesitate to contact our security team at security[at]stytch[dot]com.