SAML's rough quarter: Five critical vulnerabilities in four months

The last few months have been rough for SAML. A string of high-severity vulnerabilities has hit SAML implementations across the ecosystem, from open-source libraries to enterprise network appliances. The pattern is clear: attackers and researchers alike are treating SAML infrastructure as a high-value target, and they're finding serious bugs everywhere they look.

Here's a breakdown of the most significant recent SAML vulnerabilities, what they mean for your stack, and how to stay ahead of them.

Citrix NetScaler memory disclosure, actively exploited (CVE-2026-3055)

This is the most urgent one. In late March 2026, Citrix patched a critical memory overread vulnerability (CVSS 9.3) in NetScaler ADC and NetScaler Gateway. The flaw affects appliances configured as a SAML Identity Provider, which is a common setup for organizations using centralized SSO.

The vulnerability stems from insufficient input validation in the SAML processing logic. An unauthenticated attacker can send crafted requests to the /saml/login endpoint and trigger the appliance to leak memory contents via the NSC_TASS cookie. No credentials, no user interaction required.

WatchTowr published a two-part analysis showing that CVE-2026-3055 actually covers multiple distinct memory overread bugs across several endpoints, not just one. Their second post demonstrated that a vulnerable appliance will, in their words, "leak memory all over the place," returning kilobytes of data per request, including authenticated administrative session IDs. Within days of the patch being published, honeypot operators at Defused Cyber observed active reconnaissance, with attackers probing /cgi/GetAuthMethods to identify which NetScaler instances were configured as SAML IDPs. By March 29, active exploitation was confirmed in the wild. CISA added the CVE to its Known Exploited Vulnerabilities catalog on March 30.

This vulnerability is particularly dangerous because SAML IDPs are trust anchors. They issue tokens, validate assertions, and manage identity federation across cloud services and SaaS applications. A memory leak from a SAML IDP could expose active session tokens, letting an attacker impersonate any user with an active session across every service federated through that IDP.

If you're running NetScaler, the fix is straightforward: check whether your appliance is configured as a SAML IDP by searching your configuration for add authentication samlIdPProfile, and upgrade to 14.1-66.59, 13.1-62.23, or 13.1-37.262 immediately. Researchers have drawn comparisons to CitrixBleed (CVE-2023-4966) and CitrixBleed2 (CVE-2025-5777), both of which were rapidly weaponized after disclosure.

PortSwigger's "The Fragile Lock" (CVE-2025-66568, CVE-2025-66567)

Presented at Black Hat Europe in December 2025, this research from PortSwigger's Zakhar Fedotkin is one of the most technically impressive SAML attacks in recent memory. It demonstrates full authentication bypass in the Ruby and PHP SAML ecosystems by exploiting parser-level inconsistencies that most defenders wouldn't think to look for.

The core insight is that many SAML libraries use two separate XML parsers for different phases of signature validation. In Ruby-SAML's case, REXML handles some operations while Nokogiri handles others. Fedotkin discovered that subtle differences in how these parsers interpret namespaces, attributes, and canonicalization rules can be exploited to make the signature validation module see one document while the assertion processing logic sees another.

The research introduces several novel attack classes: attribute pollution (abusing XML namespace handling to confuse parser behavior), namespace confusion without DTDs (bypassing prior mitigations that blocked DOCTYPE declarations), and void canonicalization attacks (a new technique that exploits how XML canonicalization algorithms handle certain edge cases). The combined result is that an attacker can bypass XML signature validation entirely while presenting a perfectly valid SAML document to the application.

Fedotkin demonstrated the attack live against a GitLab Enterprise Edition 17.8.4 instance and released an open-source toolkit for identifying parser discrepancies in other SAML deployments.

The affected Ruby-SAML versions were patched in December 2025 (CVE-2025-66568 and CVE-2025-66567, fixed in versions prior to 1.18.0). PHP-SAML libraries relying on Rob Richards' xmlseclibs were also affected, with a fix released in version 3.1.4.

The broader takeaway is sobering. This research built directly on patches from a prior vulnerability and showed they were insufficient. As Fedotkin noted, incremental fixes to SAML's XML signature validation keep failing because the underlying architecture, built on multiple XML parsers with subtly different behaviors, is inherently fragile.

Authentik SAML assertion injection (CVE-2026-25922)

Disclosed in February 2026, this vulnerability affects authentik, a popular open-source identity provider. The flaw exists when a SAML source is configured to verify assertion signatures but not response signatures, or when no encryption certificate is configured.

In that configuration, an attacker can inject a malicious SAML assertion before the legitimately signed one. Authentik processes the assertions in order and uses the attacker's forged assertion instead of the real one. The result is that an attacker can impersonate any user and gain full access to the system.

The vulnerability is rated high severity (CVSS 8.8) and was fixed in authentik versions 2025.8.6, 2025.10.4, and 2025.12.4.

This bug is a textbook example of a subtle SAML configuration gap. The SAML spec allows signing at either the response level or the assertion level (or both), and implementations that only check one layer leave an opening for injection attacks at the other. It's the kind of thing that's easy to get wrong if you're building SAML processing yourself.

OneUptime SAML auth bypass (CVE-2026-34840)

Disclosed on April 2, 2026, this is almost the exact same class of bug as the authentik vulnerability. OneUptime, an open-source monitoring and observability platform, had a SAML SSO implementation (CVSS 8.1) where signature verification and identity extraction were handled by two different code paths using two different libraries.

The isSignatureValid() function verified the first <Signature> element in the XML DOM using xml-crypto, while getEmail() always read from assertion[0] via xml2js. An attacker could prepend an unsigned assertion containing an arbitrary identity before the legitimately signed one. The signature check passed (it found a valid signature in the document), and then the identity extraction grabbed the wrong assertion (the attacker's). Full authentication bypass.

This was fixed in OneUptime version 10.0.42.

The fact that this is essentially the same bug as the authentik vulnerability, discovered independently in a completely different codebase, says something important about how easy this mistake is to make. When signature verification and assertion processing are decoupled, and especially when they rely on different XML parsing libraries, the door is wide open for injection attacks. It's a structural problem in how people build SAML, not a one-off coding error.

Cisco Secure Firewall SAML DoS (CVE-2026-20101)

Published in March 2026, this high-severity vulnerability (CVSS 8.6) affects the SAML 2.0 SSO feature in Cisco Secure Firewall ASA and FTD software. An unauthenticated remote attacker can send specially crafted SAML messages to the device's SAML service and trigger a device reload, causing denial of service.

The root cause is insufficient error checking during SAML message processing. The SAML service doesn't adequately validate incoming messages, so malformed input causes a crash rather than a graceful error. The attack requires nothing more than network access to the SAML endpoint.

While this is a DoS rather than an authentication bypass, taking down a firewall's SAML endpoint can have cascading effects. If your VPN or remote access infrastructure relies on SAML SSO through a Cisco firewall, a crash-and-reload cycle can lock out your entire remote workforce and potentially create a window where security controls are degraded during reboot.

The pattern: Identity infrastructure is a persistent target

These vulnerabilities span different vendors, codebases, and languages, but they share a common thread: SAML's XML foundations continue to produce serious security issues at a rate that should concern anyone relying on the protocol.

A few observations worth internalizing:

• ‍The XML parsing surface is enormous. SAML's security model depends on XML digital signatures, which in turn depend on XML canonicalization, namespace resolution, and parser behavior. Each of these layers has produced exploitable bugs. PortSwigger's research shows that even after multiple rounds of patching, parser inconsistencies keep creating new attack paths. This is not a problem that gets solved with one fix.‍
• Edge devices are high-value SAML targets. The Citrix and Cisco vulnerabilities both target network appliances that sit at the perimeter and handle SAML processing. These devices often run proprietary or lightly audited SAML implementations, and because they sit at the network edge, they're directly reachable by unauthenticated attackers. The Citrix bug in particular shows how a SAML IDP compromise can cascade across an entire federated environment.‍
• Configuration details matter. The authentik vulnerability only manifests in a specific signing configuration. The Citrix bug only affects SAML IDP mode. These are not exotic setups; they're common in production, but they're the kind of detail that gets overlooked during security reviews because "it works" is usually good enough until it isn't.

What to do about it

If you're building or maintaining applications that use SAML-based SSO, here are concrete steps:

• ‍Audit your SAML dependencies. Know which libraries and versions you're running. If you're using Ruby-SAML, ensure you're on a version that includes the December 2025 fixes. If you're on authentik, update past the February 2026 patches. Check your transitive dependencies too; your framework may pull in a SAML library you didn't choose directly.‍
• Patch edge devices immediately. NetScaler and Cisco Secure Firewall both have patches available. If your appliances are configured as SAML IDPs or use SAML-based SSO, treat these as emergency patches, not routine maintenance. The Citrix vulnerability is already being actively exploited.‍
• Verify both response and assertion signatures. The authentik vulnerability is a reminder that partial verification is barely better than none. If your SAML implementation gives you the option to verify signatures at both the response and assertion level, enable both. If it doesn't, that's a red flag.‍
• Consider whether SAML is still the right choice for new integrations. OIDC/OAuth 2.0 carries its own risks, but it avoids the XML parsing complexity that's at the root of most SAML vulnerabilities. For new integrations where you have a choice, the simpler protocol surface of OIDC is worth considering. Of course, SAML isn't going anywhere for the vast installed base of enterprise SSO, so the priority is defense in depth for what you already have.‍
• Don't roll your own SAML parsing. If PortSwigger's research shows anything, it's that getting XML signature validation right is extraordinarily difficult. Use well-maintained, actively audited libraries, and keep them updated. If you need deeper control, at minimum avoid libraries that depend on libxml2 bindings, as they inherit a long history of parsing quirks. WorkOS covered this topic in depth when we wrote about SAMLStorm last year.

SAML has been the backbone of enterprise SSO for two decades, and it's not going away. But the protocol's XML foundations are showing their age in ways that directly translate to authentication bypasses and data leaks. The last four months have made that painfully clear.

Every vulnerability in this article required deep knowledge of XML canonicalization, signature wrapping, parser inconsistencies, or memory-level protocol handling to find, fix, and verify. That's not a side project. It's a full-time job, and it never stops. New CVEs keep coming, patches need to be evaluated and deployed quickly, and edge cases in the SAML spec keep surfacing years after everyone assumed they were settled.

This is why we built WorkOS. We maintain our own SAML implementation from scratch, specifically so we can respond to vulnerabilities like these within hours, not weeks. When SAMLStorm hit last year, we had a fix deployed for all customers within 24 hours. When PortSwigger published The Fragile Lock, our implementation was already unaffected because we don't rely on the dual-parser architecture that made the attack possible.

If you're maintaining your own SAML integration, every vulnerability on this list is now your responsibility to assess, patch, and monitor. If you'd rather ship features instead, we can handle it for you.