Skip to content

CONCEPT Cited by 1 source

SAML authentication bypass

A SAML authentication bypass is any vulnerability that lets an attacker log in as an arbitrary user of a SAML-protected service-provider (SP) without the corresponding identity-provider (IdP) authenticating that user. The severity is typically critical — one bypass gives full account takeover of every user of every affected tenant, often with no log trail distinguishable from legitimate logins.

The SAML SSO HTTP-POST binding flow has three moving parts:

  • IdP holds the private key that signs SAML responses / assertions.
  • SP holds the IdP's public key (or a cert / a metadata URL) and verifies every received SAML response's signature.
  • Browser carries the SAML response from IdP to SP.

A bypass exists whenever the SP accepts a SAML response as valid without the IdP having actually produced it for the claimed user.

Canonical bypass families

  • XML Signature Wrapping — the signed bytes and the interpreted bytes diverge. Arbitrary assertion content with a valid signature from another context passes verification.
  • Signature stripping — SP accepts unsigned assertions if the response is signed (or vice versa), and the attacker strips the inner signature but preserves the outer.
  • Algorithm confusion — SP accepts a signature computed with a weaker algorithm than configured (MD5 / no-op / symmetric-key masquerade as asymmetric).
  • Key confusion — SP accepts a signature against any key it has cached, not specifically the configured IdP's key; compromise of any IdP that ever federated in lets the attacker sign for every IdP.
  • Audience restriction missing — SP accepts an assertion meant for a different SP.
  • Timestamp / nonce replay — SP doesn't enforce NotBefore / NotOnOrAfter or doesn't deduplicate assertion IDs; an intercepted single assertion logs the attacker in repeatedly.
  • Canonicalisation-tied bypasses — specific cases where attacker-controlled content gets canonicalised differently across signing and verification.

The ruby-saml 2025 CVEs (CVE-2025-25291, CVE-2025-25292) are the XML Signature Wrapping via parser differential subcategory — the signed bytes belong to one <Signature> element while the digest/assertion comparison belongs to another, because two different XML parsers each return a different element for the same XPath query.

Attacker precondition

For the ruby-saml 2025 bypass, the attacker needs any single valid signature produced by the target organisation's IdP key. Sources:

  • Any signed assertion from any (unprivileged) user — easy if the attacker is a low-privilege user of the federation.
  • Published IdP metadata — some IdPs publish their SAML metadata (containing a self-signed document) on the open web; the metadata's signature is produced by the IdP's signing key, which is the same key the SP verifies responses against. This means no authenticated access is required in some deployments.

The bypass then fabricates an assertion for any target user (often the organisation's admin), wraps it in a SAML response that the attacker hand-crafts, and submits it to the SP. The SP verifies what it thinks is a valid signature, extracts the attacker's fabricated user claim, and issues a session.

Detectability

The ruby-saml disclosure explicitly states: "We are not aware of any reliable indicators of compromise." The class is fundamentally hard to detect server-side because, from the SP's perspective, the signature verified and the digest verified — the logs look like a normal login. Best-effort behavioural heuristics:

  • IP/geolocation drift for SAML logins — a typical SP-side check.
  • Unexpected NotBefore / NotOnOrAfter / issuer-skew flagging.
  • Assertion-ID uniqueness enforcement — catches replay but not forgery.
  • IdP-side corroboration — the IdP never emitted a response for that user at that time, so log-cross-referencing IdP logs with SP logs can catch discrepancies (expensive, often organisationally hard).

Blast radius

A single working bypass typically affects every user of every tenant of the vulnerable SP. Compromises of popular SAML stacks therefore produce fleet-wide auth-failure risk. ruby-saml is used by popular open-source projects (notably GitLab) and the downstream chain (e.g. omniauth-saml) must also be updated to reference a fixed ruby-saml version.

Mitigation ladder

  • Patch the library (highest priority, required) — ruby-saml ≥ 1.18.0.
  • Remove multi-parser split in the verification path — the long-term architectural fix; see patterns/single-parser-for-security-boundaries.
  • Pin subsequent extractions to already-verified bytes — after <SignedInfo> is cryptographically verified, do not re-query the document to recover <DigestValue> / <Reference> / transforms.
  • Consider a different protocol — OIDC, OAuth2 + mTLS, or WebAuthn-based identity federation avoid XML-DSig entirely and are less attack-surface-rich; the ruby-saml post cites an external argument that "it's probably best to disregard the specifications" when implementing SAML because the spec structure itself encourages unsafe patterns.

Seen in

Last updated · 200 distilled / 1,178 read