By ByteBot
Trail of Bits published “SAML: A Fractal of Bad Design” this week, calling for full deprecation of the 23-year-old authentication protocol. This isn’t a vendor’s marketing take or a hot-take blog post — Trail of Bits is one of the most respected security research firms in the field. Their verdict lands alongside five critical SAML CVEs in 2026 alone: a CVSS 9.3 Citrix memory disclosure, three separate authentication bypass flaws, and a CVSS 8.6 Cisco DoS. The conclusion is hard to escape — SAML’s problems are structural. You cannot patch your way out of a broken design.
The Architecture Is the Bug
SAML uses “enveloped signatures” — the cryptographic signature lives inside the XML document being validated. To verify that signature, implementations must first canonicalize the XML (convert it to a consistent byte representation), then validate the signature against that normalized form. This process, called C14N, is notoriously difficult to implement correctly across different XML libraries. And that difficulty is exactly where attackers live.
Thomas Ptacek of Trail of Bits put it plainly: “What’s insidious about SAML is that it really is mostly straightforward to understand, but it’s built on a foundation of sand, bone dust, and ash; it works… if you assume XML signature validation is reliable.” That assumption has been wrong for at least 14 years. OIDC’s JWT model flips the design: the signature is detached, separated from the payload by a period delimiter. No canonicalization. No parser differential. No attack surface from that direction. The contrast isn’t subtle.
XML Signature Wrapping (XSW) attacks — where an attacker restructures a signed XML document so the signature validates but the service provider processes attacker-controlled content — were first documented at USENIX in 2012. PortSwigger published novel variants in late 2025 with their “Fragile Lock” research, introducing “attribute pollution” and “void canonicalization attacks” against Ruby-SAML and PHP-SAML. Fourteen years of the same attack class, still producing critical CVEs. That’s not a maintenance problem. That’s a design problem.
Five CVEs, One Root Cause
WorkOS catalogued what they called SAML’s “rough quarter” — five critical vulnerabilities in four months. The list reads like a security researcher’s highlight reel. CVE-2026-3055 hit Citrix NetScaler with a CVSS 9.3: unauthenticated attackers could hit the /saml/login endpoint and leak memory — session IDs, authenticated tokens — across federated services. No credentials required.
CVE-2026-25922 (Authentik, CVSS 8.8) and CVE-2026-34840 (OneUptime, CVSS 8.1) exploited the same architectural mistake from different angles. Both implementations verified signatures at one layer and extracted identity information at another — separate code paths, separate XML parsers in some cases. Injecting a malicious assertion before the legitimately signed one was enough to authenticate as any user. Meanwhile, CVE-2026-20101 gave attackers an unauthenticated DoS against Cisco Secure Firewall by sending malformed SAML messages that triggered a device reload. Perimeter security equipment, taken offline with a crafted XML payload.
WorkOS identified three shared root causes across all five: XML parsing complexity creating exploitable parser differentials, signature verification and assertion processing operating as decoupled systems, and perimeter devices running proprietary SAML stacks without adequate security review. These aren’t bugs that got introduced. They’re structural features of SAML that keep generating vulnerabilities in every new implementation.
Related: Patch Tuesday September 2026: 974 CVEs, Two Zero-Days
A Protocol Designed for 2003
SAML 2.0 was finalized in 2005, before universal HTTPS, before REST APIs dominated, before the iPhone shipped. It was designed for disconnected corporate networks that couldn’t assume direct communication between identity providers and service providers. Those assumptions are now universally wrong. OIDC was built for the modern internet — it assumes HTTPS, assumes connected topology, and supports backchannel communication that reduces payload complexity dramatically. A typical SAML assertion runs ~5KB of XML. A JWT runs ~1KB.
SAML was also a committee product. It merged four competing protocols — S2ML from Netegrity, AuthXML from Securant, X-TASS from VeriSign, and ITML from Jamcracker — into a single specification. Modern implementations use roughly 10% of that spec. The other 90% is unused attack surface, maintained for compatibility with integrations no one has audited in years. Trail of Bits notes that companies like Fly.io and Tailscale simply avoided SAML entirely when building their auth stacks. OIDC was sufficient. The lesson wasn’t subtle — they knew what they were avoiding.
Start the Migration
The good news is that the migration playbook is established. The friction is real but manageable. Trail of Bits recommends that identity providers stop onboarding new SAML customers immediately, offer OIDC-equivalent configurations, and set sunset dates for existing integrations. For service providers, the first step is the same: stop adding SAML connections. Every new integration that goes in is another one to migrate later.
For legacy applications that only speak SAML, the practical bridge is an OIDC-to-SAML proxy — a translation layer that lets you migrate the application layer first, then move the legacy app independently. GitHub’s enterprise migration flow shows the pattern: disable SAML, install OIDC application, re-provision users. Industry data puts the failure rate for legacy protocol migrations at 40% without a dedicated proxy or modernization plan — which is a reason to plan carefully, not a reason to delay. The next SAML CVE isn’t a question of if. It’s a question of which implementation and when.
Key Takeaways
- SAML’s enveloped signature model and XML canonicalization requirement are structural flaws — not bugs that can be patched out of existence
- Five critical SAML CVEs in 2026 (CVSS 9.3, 8.8, 8.8, 8.6, 8.1) all trace back to the same root causes: parser complexity, decoupled verification, and C14N handling
- XML Signature Wrapping attacks have been documented since 2012 and are still producing new CVE variants in 2026 — architectural inevitability, not bad luck
- OIDC’s JWT model eliminates the canonicalization problem by design: detached signatures, JSON payloads, ~1KB vs ~5KB
- Stop onboarding new SAML integrations now; use OIDC-to-SAML proxies for legacy apps; set sunset dates for existing connections
