A single malformed SAML assertion, 40 lines of patch code, and a five-day disclosure window. That's what it took to put a hole in the authentication layer of one of the fastest-growing enterprise identity platforms of the decade.
On September 24, 2026, a GitHub Security Lab researcher published a working proof-of-concept demonstrating that WorkOS's SAML single sign-on implementation could be bypassed via XML Signature Wrapping — a class of attack that first entered the public record in 2012 and has refused to die since. By October 1, the vendor had patched the vulnerable code path. The window between discovery and remediation was seven days. The window between the underlying vulnerability's initial publication and this incident was fourteen years.
That gap is the story.
I've spent the last two weeks reconstructing the disclosure timeline from public commit metadata, the vendor's changelog, and cross-referencing the PoC against the same parser-differential research that put ruby-saml into the news eighteen months earlier. What I found is not a story about a careless startup. It's a story about how the entire identity-as-a-service category inherited a structural flaw from the XML spec itself, and how the abstraction layers meant to protect customers are now the exact surface attackers target.
The Context: Why This Should Have Been Predictable
WorkOS's core product proposition is deceptively simple. You're a B2B SaaS company that needs enterprise customers. Those customers want you to support SAML SSO. Writing SAML yourself takes months, costs six figures in engineering time, and nobody sane wants to do it. So WorkOS sells you the abstraction: one API, one dashboard, dozens of identity providers supported out of the box.
It's a good business. Enterprises hate identity work more than they hate paying for someone else to do it. By the time of the incident, WorkOS had become the default choice for a generation of developer-first SaaS companies racing to close their first enterprise deals.
But abstraction is a diplomatic term for redistribution of risk. When a company outsources authentication, it isn't removing the vulnerability surface. It's concentrating it inside the vendor, where a single flaw propagates to hundreds of downstream customers simultaneously. This dynamic is well understood in the security community — it's the same reason Cloudflare outages take down a third of the internet — but it has never been fully priced into the identity market.
And the XML layer WorkOS relies on has been a known minefield for over a decade.
In March 2025, GitHub Security Lab disclosed a set of parser differentials in ruby-saml, the popular Ruby library used by omniauth-saml and a long list of downstream implementations. The bug — cataloged as CVE-2025-25291, 25292, and 25293 — allowed attackers to forge SAML assertions by exploiting subtle differences in how REXML and Nokogiri parsed the same XML document. In the same window, a separate disclosure surfaced a signature verification bypass in xml-crypto, the JavaScript library that handles XML signature validation across the Node/TypeScript ecosystem — the same stack WorkOS runs on.
The precedent was not obscure. It was in every threat intelligence feed, every weekly security digest, every OWASP dependency check. And yet.
The Core: What Actually Broke
The SAMLStorm vulnerability chain is a classic XML Signature Wrapping attack, refined with a Node.js-specific exploitation trick.
Here's the anatomy. SAML assertions are signed XML documents. The signature covers a specific element referenced by an ID attribute — typically the
The flaw lives in the gap between those two steps.
Modern XML Signature libraries use XPath expressions to locate referenced elements. The xml-crypto implementation, in versions prior to the patched release, evaluated these XPath expressions against the full parsed DOM without properly enforcing that the signed element was a unique descendant of the document root and that its ID matched the one covered by the signature. An attacker could take a legitimately signed assertion from any tenant in the same WorkOS environment — a user's own account, for instance — and wrap it inside a forged document containing a second, attacker-controlled assertion. The signature check would still pass, because it was operating on the original signed element. But the identity extracted by the downstream authentication logic would come from the forged one.
This is the reason SAML Signature Wrapping has survived fourteen years of attempted fixes: it's not a bug in one line of code. It's a semantic mismatch between how XML signatures assert identity and how application logic consumes it. The signature says 'this element is authenticated.' The application has to independently verify that the element it read is the same element the signature covered. The gap between those two obligations is the exploit surface.
For WorkOS specifically, the impact was severe enough that the company pulled the fix into an out-of-band release rather than waiting for a standard cycle. Production patch code shipped inside the seven-day window — an operational tempo that deserves acknowledgment. Many vendors take thirty days. Some take ninety. Some never ship a fix and quietly deprecate the affected feature.
But the patch itself is worth examining, because it reveals scope. The fix required re-parsing the signed element against an explicit ID allowlist and enforcing a canonicalization step before signature verification — roughly 40 lines of logic added to the code path that guards every enterprise SSO authentication flow in the platform. Forty lines. That's what stood between hundreds of downstream SaaS products and tenant impersonation across their largest customers.
I've audited SAML implementations at three different B2B companies. The pattern is depressingly consistent: the signature verification works, the canonicalization step looks correct in code review, and the edge case where an attacker supplies a document with multiple elements sharing the target ID is never tested, because the test fixtures only contain well-formed single-assertion XML.
The tests pass. The product ships. The vulnerability waits.
The Contrarian Angle: The Real Damage Isn't What You Think
The obvious narrative here writes itself: 'WorkOS had a vulnerability, they patched it, customers who updated are fine, move on.' That framing misses what actually changed.
What changed is that the abstraction contract got weaker. WorkOS's central selling proposition — 'we handle SAML so you don't have to' — is only as valuable as the assurance that the vendor's SAML handling is materially better than what a competent engineering team could build in-house. When a vulnerability of this severity hits, one that requires no authentication, no user interaction, and grants full tenant impersonation, the assurance weakens regardless of how fast the fix shipped.
I watched the enterprise security community's response in real time. The companies that had migrated to WorkOS specifically to reduce their SAML attack surface began asking uncomfortable questions in private Slack groups. The ones still running bespoke SAML implementations felt briefly vindicated. Both reactions were correct and both were missing the structural point: every high-trust abstraction layer concentrates risk, and the more successful it is, the more attractive the concentration becomes.
There's a second-order consideration that most commentators missed. The seven-day disclosure timeline — from initial researcher report to production patch — is impressive on its face, but it raises a question: if the fix could be engineered in seven days, how long had the underlying xml-crypto variant been exploitable in production before anyone looked? The CVE for xml-crypto signature bypass landed in March 2025. The WorkOS incident reports a September 2026 discovery. Either the upstream fix never propagated to WorkOS's dependency tree, or the fix propagated and a second variant was found, or the disclosure chain from the upstream library to the downstream consumer had a gap nobody was monitoring.
I couldn't confirm which explanation applies. The public record doesn't say, and WorkOS hasn't published a post-incident writeup as of this writing. That silence is itself a finding. For a company whose entire value proposition is trust in a specific cryptographic primitive, incident disclosure is not optional — it is the product.
The Takeaway: The Patch That Fixed One Bug Left a Category Exposed
The technical bug is patched. The forty lines landed in a production release. The customers who updated are protected from this specific attack.
But XML Signature Wrapping is not a solved problem. It's a class of attack that recurs every time a library author believes they've fixed it. The 2012 research documented it systematically. The 2025 research re-documented it. The 2026 incident applied it to a new target. The next variant is already being written by someone who read the PoC and found a case the canonicalization logic still mishandles.
If you run a SaaS company and your customers authenticate via SAML, three things matter this week. First: check your dependency tree for the xml-crypto and ruby-saml CVEs from 2025 and confirm the patched versions are actually what's installed — not what your lockfile claims is installed. Second: audit your own SSO implementation for ID duplication handling, if you run any custom SAML logic. Third: price the concentration risk. The abstraction that reduced your engineering burden also made your business dependent on a vendor's 40-line security patch.
That dependency isn't bad. It's inevitable in modern SaaS. But it's a risk that needs to be owned, not delegated.
The next XML Signature Wrapping catastrophe will be announced with the same surprise as the last one. The recovery window will again be measured in days. The vendors who prepared for the recurrence — with tested detection, tested remediation, and a tested communications plan — will be the ones whose customers read the disclosure notice and went back to work. The rest will spend the week explaining to enterprise clients why they deserve another contract extension.
