SAML signature validation is supposed to be the trust anchor in enterprise SSO: if the assertion is signed, the session is legitimate. A class of attacks exploiting the gap between what XML canonicalization validates and what the application reads breaks that assumption. The signed assertion and the parsed assertion can be two different documents, and most SSO integrations never notice.
The Signature-Confusion Attack Class
In a signature-confusion attack, the attacker mutates a signed SAML assertion in a way that passes cryptographic verification but changes the identity the service provider reads. The mechanism exploits differences between how XML canonicalization processes a document for signature verification and how the application’s XML parser interprets the same document afterward. The signature is mathematically valid. The assertion the application trusts is not the one that was signed.
This is not a single implementation bug. It is a class of vulnerabilities inherent in how SAML 2.0’s use of XML Signature handles the boundary between cryptographic verification and application-level parsing. Both SAML 1.1 and 2.0 rely on the same XML Signature standard for authentication and message integrity, which means the attack surface is present wherever SAML is deployed.
A disclosure referred to as “SAMLStorm” reportedly demonstrates this class in practice, though specific CVE assignments, affected libraries, and technical details could not be independently confirmed as of June 2026. The canonicalization-divergence attack class itself is well-established; the disclosure’s particulars are not.
How SAML Assertion Verification Should Work (and Where It Diverges)
A standard SAML authentication flow has seven steps: the user accesses a service provider, the SP generates a SAML request, the browser redirects to the identity provider, the IdP authenticates the user, the IdP generates a signed SAML response, the browser forwards that response to the SP’s Assertion Consumer Service URL, and the SP verifies the signature before creating a session, as documented by Auth0’s SAML walkthrough.
The trust model hinges on step seven. The SP receives an assertion containing three statement types: authentication statements (when and how the user authenticated), attribute statements (name-value pairs about the user), and authorization decision statements (what the user can access), per the SAML specification. The digital signature is supposed to bind all three to the IdP’s key.
The gap opens when the XML parser that extracts the NameID, attributes, and conditions from the assertion does not process the document identically to the XML Signature library that verified the signature. Comment handling, whitespace normalization, namespace prefixes, and entity expansion can all diverge between the two code paths. When they do, the “verified” document and the “read” document are different.
Known SAML Vulnerability Families
Signature-confusion attacks sit in a landscape of established SAML attack classes, each targeting a different weak point in the verification chain.
Signature stripping. If the SP does not properly validate the digital signature, an attacker can capture a legitimate SAML response, modify the NameID to impersonate a different user, and remove the now-invalid signature. The SP accepts the modified assertion as though it were unsigned-but-trusted, as described in GeeksforGeeks’ SAML authentication overview. This is the crudest form: the signature is simply removed rather than subverted.
XML comment injection. A more subtle variant exploits comment handling in XML parsers. By injecting comments into the NameID field, an attacker can cause the parser to interpret a different identity than what was signed. The signature covers the original content, but the parser’s extraction of the NameID may strip or interpret those comments differently depending on canonicalization rules. This is documented as a known SAML attack vector by GeeksforGeeks.
Replay attacks. These exploit expired assertions rather than signature mechanics. If the SP does not enforce the NotOnOrAfter timestamp in the SAML Conditions element, a captured assertion can be replayed to establish a new session. The signature is valid; the assertion is simply stale. GeeksforGeeks identifies timestamp enforcement as the required mitigation.
The signature-confusion class extends this taxonomy by attacking not the presence or freshness of the signature, but the correspondence between what was signed and what the application reads. It is a canonicalization gap rather than a validation skip.
Why a Platform WAF Rule Is a Stopgap
A platform-level firewall rule that blocks malformed SAML assertions at the edge addresses the symptom, not the mechanism. The rule can match known exploit patterns: specific XML structures, injected comments, unexpected canonicalization outputs. But it cannot verify that the application’s XML parser and the signature library agree on what the document says.
This is structurally the same problem that makes WAF rules insufficient for SQL injection. The firewall can block known payloads, but the underlying parser-behavior divergence remains. The next mutation of the attack that does not match the rule’s pattern passes through unexamined.
The real fix requires the IdP and SP libraries to canonicalize and parse identically, or for the verification step to operate on the exact byte sequence the application reads rather than a separately canonicalized copy. That is a library-level change, not an edge-level filter. SSO operators who rely on their IdP library’s default verify path inherit the gap upstream; the WAF rule shifts the blocking responsibility to the platform without closing the root cause.
What SSO Operators Should Check
For operators running SAML-based SSO, the canonicalization gap has concrete audit points.
Identify your parser and signature libraries. If the SP uses different libraries for XML parsing and signature verification (and it almost certainly does), check whether they agree on canonicalization behavior for comments, whitespace, and namespace prefixes. Disagreement here is the vulnerability.
Test with malformed assertions. Inject XML comments into NameID fields, add unexpected namespace prefixes, include entity references. Verify that signature validation rejects the modified document. If the signature validates but the extracted identity differs from what was signed, the gap is live.
Inspect the default verify path. If your IdP library’s signature verification operates on a re-serialized copy of the assertion rather than the raw input bytes, the canonicalization gap exists by design. This is worth checking even if no CVE has been published for your specific stack.
Enforce NotOnOrAfter timestamps. Replay attacks are the low-hanging fruit. If the SP is not checking assertion expiration, fix that first, then move to canonicalization testing. GeeksforGeeks documents this as a required SP-side check.
Broader Context: SAML Security Posture After Vercel’s April Breach
As of 2026, SAML remains the dominant SSO protocol in enterprise environments despite its XML-era complexity, a position Auth0 confirms as the most used protocol for SSO in the enterprise. The specification’s age is part of the problem. XML Signature and XML canonicalization were designed when parser behavior was assumed to be consistent across implementations. The six bindings and 12 deployment combinations create a combinatorial surface that no single library can test exhaustively.
Vercel disclosed a security breach on April 19, 2026, originating from a compromised third-party AI tool called Context.ai, where an attacker breached an employee’s Google Workspace account via Lumma Stealer malware, per Vercel’s Wikipedia entry. That breach was unrelated to SAML vulnerabilities. It did, however, elevate scrutiny of the platform’s authentication surface. The company’s subsequent security hardening provides the context in which edge-level mitigations for SAML signature confusion are being deployed.
Specific details of platform-level WAF rules targeting SAML signature-confusion attacks have not been independently verified as of June 2026. The “SAMLStorm” disclosure referenced in recent coverage, including any CVE assignment and affected library list, could not be confirmed from available sources.
SAML’s trust model assumes that “cryptographically signed” and “what the application reads” describe the same document. The protocol provides no runtime mechanism to enforce that assumption. Closing the gap requires either protocol-level changes that would break backward compatibility, or per-integration auditing of the parser-signature correspondence. Neither is the kind of problem a vendor WAF rule solves.
Frequently Asked Questions
How does OIDC sidestep the canonicalization problem that SAML inherits from XML Signature?
OIDC tokens are signed JWTs, where the signature covers the exact byte sequence of the token with no canonicalization step. JSON has no XML comment injection, namespace prefix ambiguity, or entity expansion, so there is no “verify one document, read another” divergence. Teams considering SAML-to-OIDC migration for SSO can treat the absence of a canonicalization layer as a structural security advantage, not just a simplification.
Which SAML binding is most exposed to signature-confusion mutations?
The HTTP POST binding, which routes the assertion through the browser as a base64-encoded form parameter, exposes it to mutation because the browser is an untrusted intermediary. The SOAP binding, used for direct back-channel exchanges between IdP and SP over TLS, denies the attacker a point of injection. Any of the 12 SSO deployment combinations that use browser-mediated POST inherit the higher exposure.
What existing tooling can test for parser-signature divergence in a SAML integration?
OWASP ZAP includes a SAML testing plugin that injects modified assertions (comment payloads, namespace variations) into live SSO flows. For regression coverage, a custom test that signs a known assertion, applies canonicalization-divergence mutations, and asserts the SP rejects them is the reliable path. No commercial SAST or DAST scanner targets the canonicalization gap specifically as of 2026.
Could SAML adopt a non-XML signature scheme to eliminate the canonicalization gap?
The SAML specification mandates XML Signature in its binding definitions, so a replacement would require a new standard revision and break backward compatibility with every deployed IdP and SP. A practical middle ground would be a dual-signature scheme where the IdP adds a raw-byte HMAC alongside the XML Signature, but no such proposal exists on any standards track as of 2026.