Four SAML Vulnerabilities from Report to Fix: Lessons from Signature and Identity Parsing Inconsistency

SAML SSO is a cornerstone of enterprise identity authentication, but a security audit revealed four authentication bypass vulnerabilities with a strikingly consistent root cause: the same SAML response was interpreted differently during signature verification and identity extraction.

The Nature of the Vulnerability: Dual Parser Inconsistency

Why Signature Verification and Identity Extraction "Speak Different Languages"

A SAML response is a piece of digitally signed XML. The verification logic checks whether the signature covers a certain node, and then another piece of code extracts user identity attributes from the same document. The problem is that these two pieces of code often use different XML parsers, different XPath expressions, and even different ways of handling namespaces.

Attackers can exploit this discrepancy: by crafting an XML document that causes the signature verifier to see user A's data while the identity extractor reads user B's identity (typically an administrator). The signature itself is completely legitimate, but the system has been bypassed.

XML Canonicalization (C14N) is a set of algorithms defined by the W3C for converting logically equivalent XML documents into a byte-level consistent canonical form. The XML specification allows a large number of equivalent representations of the same logical document—attribute order can be swapped, namespaces can be declared at different levels, empty elements can be written as self-closing or expanded forms, and characters can be entity-escaped or written directly. These differences are equivalent at the XML Information Set level, but the byte sequences are completely different. Signature verification typically operates on byte sequences or canonicalized node sets, so if the signing party and the verifying party use different canonicalization methods, the situation of "signature passes verification but content is interpreted differently" will arise. The SAML specification requires the use of Exclusive Canonicalization (Exclusive C14N), which only includes namespace declarations that are actually used, avoiding irrelevant declarations from ancestor nodes polluting the canonicalization result. This is also a detail that must be strictly followed when fixing such vulnerabilities.

XPath and namespaces are high-risk areas for parsing ambiguity. In XPath 1.0, an unprefixed element name matches elements in no namespace, rather than elements in the default namespace, which is contrary to most developers' intuition. If the identity extraction code is written as /Response/Assertion/Subject/NameID, while these elements in the document are actually under the urn:oasis:names:tc:SAML:2.0:assertion namespace, the expression will match no nodes or match forged nodes injected by an attacker. In addition, descendant axis selections like //, the wildcard *, and the loose matching of local-name() can all cause the extractor to select a different node from the verifier. In defensive practice, absolute paths bound to explicit namespace prefixes should be used, and the namespace URI reported by the parser should be validated rather than merely comparing element local names.

Four Vulnerabilities, One Root Cause

All four disclosed vulnerabilities can be classified as authentication bypasses, and all stem from the same category of parsing ambiguity. They do not require breaking encryption algorithms or stealing private keys—only an understanding of behavioral differences between parsers is needed to craft exploitation payloads.

From a vulnerability classification perspective, such flaws are typically categorized at the intersection of CWE-436 (Interpretation Conflict) and CWE-347 (Improper Verification of Cryptographic Signature). Well-known historical cases with the same origin include the Duo Labs SAML vulnerability disclosed in 2018 (involving XML comment and namespace confusion), the GitHub Enterprise SAML bypass, and the earlier XML Signature Wrapping (XSW) attacks. The core technique of XSW is to retain a legitimate signed node while inserting a structurally similar forged node at a different position, inducing business code to read the latter. Understanding the various variants of XSW—such as copying the signature element into a forged assertion, exploiting duplicate ID attributes, and using ambiguity in the ds:Reference URI target—is necessary background for assessing whether your own implementation is secure.

From Report to Fix: The Response Process

Discovery and Confirmation

The vulnerability report was fully remediated in late September 2026. During the confirmation phase, the team focused on two things: first, reproducing each parsing discrepancy, and second, assessing which downstream business systems actually relied on the insecure parsing paths.

Remediation Strategy

The fundamental approach is to eliminate dual parsers: signature verification and identity extraction must be based on the same canonicalized XML tree. Any secondary parsing of raw bytes is a potential risk.

Practical Recommendations for Developers

Hard Rules for Handling Signed XML

• Prohibit the use of multiple parsers to process the same security-sensitive XML document
• Canonicalize (C14N) the XML before signature verification, and ensure identity extraction is based on the canonicalized result
• Strictly validate namespaces; do not rely on the implicit behavior of default namespaces
• Use absolute paths for XPath queries and avoid fuzzy matching

In terms of engineering implementation, mature libraries should be preferred and their security guidelines followed: OpenSAML and Spring Security SAML in the Java ecosystem, and ITfoxtec or Sustainsys.Saml2 in .NET all have built-in protections against XSW. If you must build your own, be sure to disable external entity resolution (XXE) and DTD processing, use a namespace-aware parser (such as Java's DocumentBuilderFactory.setNamespaceAware(true)), and verify during signature validation that the Reference URI points to the unique assertion ID in the document. At the same time, reject duplicate IDs, IDs with comments, and cases where ID, Id, and id attributes are mixed in different cases, as these are common triggers for parser divergence.

Scenarios That Should Be Covered in Testing

Security testing should not only test "whether invalid signatures are rejected," but also test "whether behavior is consistent when the signature is valid but the parsing result is ambiguous." You can construct XML samples containing duplicate nodes, nested namespaces, and comment interference to observe whether verification and extraction point to the same logical node.

Broader Implications

This type of SAML issue is not an isolated case. Any protocol that "verifies first, then parses" (including some JWT and WS-Security implementations) carries similar parser inconsistency risks. The core defensive principle is simple: security decisions and business logic must be based on the same view of the data. When the two diverge, the attack surface appears.

For teams using SAML SSO, it is recommended to immediately audit the code paths for signature verification and identity extraction in self-developed or third-party libraries to confirm whether they share the same parsing result. If the answer is no, then these four vulnerabilities should serve as a warning: the next bypass may be hiding in your own code.

One-line Summary

Four SAML SSO authentication bypass vulnerabilities share the same root cause: signature verification and identity extraction parse the same XML inconsistently.

Paragraph Summary

A security audit revealed four SAML SSO authentication bypass vulnerabilities that require no breaking of encryption or stealing of private keys. Their root cause is strikingly consistent: the same SAML response is interpreted differently during signature verification and identity extraction due to different parsers, different XPath expressions, and even different namespace handling, allowing attackers to make verification see user A while the extractor reads administrator B. The core fix is to eliminate dual parsers so that security decisions and business logic are based on the same C14N-canonicalized XML tree, with strict namespace validation and absolute paths. The article also warns that this type of "verify first, parse later" risk is common in some JWT and WS-Security implementations, and teams should immediately audit the relevant code paths.