Vercel’s changelog entry from March 2025 claims its managed firewall “automatically mitigates” the SAMLStorm vulnerability class. The same paragraph tells customers to update xml-crypto anyway. One of those statements is a useful defense layer. The other is the actual fix. The distance between them matters, because SAMLStorm exploits a split between what two XML parsers believe they signed, and no HTTP-layer firewall inspects canonicalized XML signatures.
Two CVEs, one structural flaw
SAMLStorm comprises CVE-2025-29774 and CVE-2025-29775, both rated CVSS 9.1 critical, affecting xml-crypto versions 6.0.0 and below and the node-saml library. The attack requires only a valid IdP account. No cryptographic key compromise is needed.
CVE-2025-29775, the DigestValue Comment Injection variant, works by inserting an XML comment inside the <ds:DigestValue> element. The xml-crypto library reads only the text node after the comment (the legitimate hash), so the signature verification passes. Meanwhile, the assertion content has been swapped to carry a different NameID, such as admin. The signature check and the identity extraction operate on different views of the same document.
CVE-2025-29774 exploits a separate XML parsing inconsistency in the same library. Both CVEs share the same structural root: xml-crypto validates the signature against one view of the assertion while node-saml extracts identity claims from another. The parsing path that enables the split differs between the two.
The fix shipped in xml-crypto 6.0.1, released in March 2025 alongside the disclosure, with backported patches for the 3.x branch (3.2.1) and 2.x branch (2.1.6). The patch addresses how xml-crypto processes DigestValue and SignedInfo nodes to prevent the parser-split attack.
What Vercel’s firewall actually inspects
Vercel Firewall operates at the HTTP layer, applying managed OWASP rulesets (covering XSS, SQLi, LFI, RFI, and RCE), custom traffic rules, and IP-based blocking. There is no documented capability for XML canonicalization validation, SAML assertion parsing, or signature verification at the edge.
This is not a gap in Vercel’s implementation. It is a structural limitation of HTTP-layer inspection. A WAF can inspect incoming request payloads, but what it cannot do is determine whether the signed portion of a SAML assertion corresponds to the identity the relying party will extract. That determination requires parsing the XML with the same canonicalization algorithm the IdP used, recomputing digests, and comparing them against the signed digest values. This is application-layer cryptographic validation, not traffic-shape filtering.
Vercel does not disclose how its firewall detects SAMLStorm attempts. Whether it uses payload-length heuristics, XML structure fingerprinting, or signature-based pattern matching is not documented. What is documented is the explicit recommendation in the same changelog entry to update xml-crypto to a patched version.
The dashboard signal problem
Vercel’s April 2026 security breach, in which a threat actor accessed an employee’s Google Workspace through the compromised AI tool Context.ai, refocused attention on the platform’s security posture. According to Wikipedia, a threat actor claiming to be part of ShinyHunters claimed responsibility and listed exfiltrated data for $2 million on BreachForums, though the post was later deleted and the group denied involvement. The breach itself did not involve SAMLStorm. But the renewed scrutiny makes the gap between “firewall-protected” and “actually patched” more consequential.
For operators running SAML integrations on Vercel, the practical sequence is straightforward. Patch xml-crypto (or any SAML library in the stack) to the version that reads assertions from verified content. Enable MFA at the IdP, since SAMLStorm requires a valid authenticated session to craft the malicious assertion. Log ACS-endpoint requests with enough detail to reconstruct the assertion content post-incident. Treat the WAF rule as a detection layer that raises the cost of noisy attacks, not as a replacement for library-level signature validation.
The Vercel firewall rule is not useless. It will catch unsophisticated attempts and reduce noise. But the changelog’s own recommendation to patch the library is the more honest statement about what the WAF can and cannot do here, and operators who stop at the dashboard badge are trusting the wrong layer of the stack.
Frequently Asked Questions
Does SAMLStorm affect Ruby or PHP SAML libraries, or only Node.js?
PortSwigger Research demonstrated the same signature-wrapping class against ruby-saml and php-saml in December 2025, under the name “The Fragile Lock” (CVE-2025-66568), with a live demo against GitLab EE 17.8.4. A WAF rule tuned to xml-crypto exploit patterns would not catch these variants. The structural weakness is in how SAML libraries split XML parsing from cryptographic verification, not in any single runtime.
What specific WAF operators could even attempt to catch a SAMLStorm payload?
Vercel Firewall supports pattern matching operators (eq, re, inc, pre) applied to HTTP request properties including path, headers, cookies, IP, user-agent, and geo data. Detection would have to rely on byte-pattern matching inside the POST body, such as spotting XML comment syntax within a DigestValue element. A request that encodes the comment differently, or exploits the duplicate-SignedInfo path (CVE-2025-29774) without comments, would not match those signatures.
What should ACS-endpoint logs capture to enable post-incident forensics?
The vulnerability is classified CWE-347 (Improper Verification of Cryptographic Signature). Logs need the full SAMLResponse POST body, not just request headers or status codes. Without the raw assertion, investigators cannot compare the signed digest against the NameID that the relying party actually extracted, which is exactly the comparison that determines whether a signature-wrapping attack succeeded.
Which confirmed production platforms were affected beyond Vercel?
WorkOS and multiple SaaS products built on node-saml were confirmed vulnerable. xml-crypto backported fixes to three branches (6.0.1, 3.2.1, and 2.1.6), which indicates a wide installed base across major and minor versions. Any service that deferred the patch because a WAF badge showed “protected” remained exploitable by an authenticated IdP user impersonating an admin.