The name “SAMLStorm” labels a resurgent class of XML Signature Wrapping (XSW) attacks against SAML-based single sign-on. As of this writing, the term does not appear in any public CVE database, vendor advisory, or primary-source disclosure that Groundy could independently verify. What is verifiable, and what this article covers, is the underlying attack class: a family of canonicalization exploits that have been documented for years and are demonstrably not solved. The analysis below is anchored to the well-documented XSW mechanics, not to the specifics of any single 2026 disclosure.
How XML Signature Wrapping Works
SAML 2.0 uses XML Signature to authenticate assertions passed between an identity provider (IdP) and a service provider (SP). The IdP signs the assertion. The SP verifies the signature and grants access. The cryptography is sound. The vulnerability is in how parsers locate the signed content.
An XSW attack exploits the gap between signature validation and data processing. The attacker captures a legitimate SAML response, preserves the signed assertion intact (so the signature still validates), and injects a forged assertion elsewhere in the XML document. The SP’s signature checker verifies the original signed element and returns “valid.” The SP’s application logic then reads the first assertion it encounters, the forged one, and processes it as authenticated data.
IBM’s description of the attack explains the mechanism: the attacker injects a duplicate or manipulated element outside the signed portion, and the application processes the malicious data instead. The application grants access based on the unsigned forged element. The signature was never broken. It validated the wrong thing.
The root cause across all wrapping variants: the signature verifier and the application parser use different logic to locate “the assertion.” When those paths diverge, the attacker controls the gap.
Why This Attack Class Refuses to Stay Dead
XSW has been documented as a vulnerability class in SAML implementations for years. Remediation efforts have focused on strict canonicalization: ensuring that the parser and the verifier resolve the same node.
The recurrence is structural, not incidental. SAML’s trust model delegates signing to the IdP and verification to the SP, with no standard mechanism for the SP to confirm that the assertion it processed is the same one the signature covered. Microsoft’s SAML overview notes that system clock checks protect against replay attacks, but replay protection is orthogonal to wrapping. A wrapped assertion is not replayed; it is replaced in place. The protocol assumes that the XML processor behaves deterministically, and that assumption is false across enough real-world parsers to keep the attack viable.
New SAML integrations ship daily, many wired by developers working from framework tutorials that gloss over canonicalization. The attack surface grows with every new SP. The defensive knowledge does not grow at the same rate.
The Limit of Edge Mitigations
The response angle that “SAMLStorm” has prompted is a platform-level one: WAF rules at the edge that detect signature-confusion patterns in SAML traffic. Vercel’s security documentation describes a Web Application Firewall that allows customers to create custom rules to log, block, challenge, or rate-limit L7 traffic. The appeal is obvious. Drop a rule, protect every SP behind the edge, skip the library patches.
This is a delaying tactic, not a fix. A WAF signature matches known XSW patterns: specific element reorderings, duplicate ID attributes, known malformations. It does not protect against novel wrapping variants. The space of possible XML restructurings that preserve a valid signature while misdirecting the parser is effectively unbounded.
Vercel itself disclosed a security breach in April 2026, originating from a compromised third-party AI tool (Context.ai), which led to unauthorized access to some environments and environment variables. The incident is a reminder that identity-adjacent infrastructure at edge platforms is an active target, not a passive shield. A WAF rule deployed on a platform that has already been breached through an unrelated vector provides defense in breadth, not defense in depth.
Where the Real Fix Lives
The durable mitigation for XSW is canonicalization rigor inside the SAML library itself. The requirements are specific:
Verify-then-process atomicity. The library must extract the exact node set that was signed, verify the signature over that node set, and process only that node set, all in a single code path that does not allow the application to reference a different node.
Strict ID resolution. Reject documents with duplicate ID attributes. The XML specification requires unique IDs, but many parsers are permissive.
Canonicalization consistency. The canonicalization algorithm used during verification must produce the same byte sequence as the one used during signing. In practice, differences in whitespace handling, namespace prefix resolution, and attribute ordering between implementations create exploitable gaps.
No fallback to positional resolution. If the library locates an assertion by position (“the first
<Assertion>element”) rather than by the signed element’s reference URI, it is vulnerable to simple wrapping by construction.
These are library-level responsibilities. No proxy, WAF, or edge rule can enforce them on the SP’s behalf, because the SP must eventually deserialize the XML, and the deserialization happens inside the library.
The Broader Pattern: Identity Protocols as Perennial Targets
SAML is not unique in this dynamic. Any protocol where a signed token is passed through an intermediary format that allows structural ambiguity will produce the same class of vulnerability. IBM’s overview notes that XSW applies to SOAP and WS-Security as well as SAML. WS-Security, which shares XML Signature with SAML, has the same XSW surface by construction.
The recurring pattern: the protocol’s cryptographic guarantees are sound, but the serialization format creates a gap between what was signed and what is processed. The gap is filled by implementation-specific canonicalization behavior, and implementations vary. Every few years, someone rediscovers that a popular implementation fills the gap incorrectly, and the CVE cycle repeats.
The responsible position for engineering teams is to treat SAML library patches as mandatory, not optional, and to treat edge WAF rules as temporary compensating controls while those patches land. Anything else is a bet that the next XSW variant will match a signature the WAF already knows about.
Frequently Asked Questions
What are the five XSW subtypes and which parser behavior does each target?
IBM documents five distinct subtypes: simple wrapping (move the signed element and insert a forged one), ID-based wrapping (duplicate an element with the same ID attribute), namespace injection wrapping (manipulate XML namespace declarations to confuse the verifier), enveloped signature abuse (reposition the Signature element so validation covers the wrong portion of the document), and XPath injection wrapping (manipulate XPath queries to resolve to attacker-controlled nodes). Each targets a different assumption about how the parser locates content, so patching one subtype does not prevent the others.
Which SAML libraries were hit in the 2012-2018 XSW CVE wave?
ruby-saml (CVE-2017-11427) and python3-saml (CVE-2017-11426) are the most widely cited instances. Both allowed an attacker to forge a SAML response that passed signature verification while the application processed a different, unsigned assertion. The same class also affected several WS-Security implementations, because SOAP-based protocols share XML Signature with SAML and inherit the same canonicalization gaps by construction.
Does SAML’s XML Encryption layer introduce a separate attack surface beyond signature wrapping?
Yes. The SAML specification uses XML Encryption for encrypted assertions, and that encryption layer itself carries documented severe weaknesses. An attacker who can exploit both the signature wrapping gap and the encryption layer’s flaws faces a compound risk surface where neither the integrity check nor the confidentiality wrapper is trustworthy in isolation.
What is the first test to run against a SAML integration to check for XSW exposure?
Send a valid SAML response with the signed assertion relocated into a new wrapper element and a forged assertion (with a fabricated NameID) inserted at the document’s top level. If the SP grants access to the forged identity, the integration is vulnerable to the entire XSW class, not just the simple wrapping variant. This test requires only a SAML response capture and an XML editor, no specialized tooling.