Federation trust abuse and SAML forgery

A service provider that accepts a SAML assertion it should have rejected treats a forged identity as authenticated, because the failure sits in signature validation code, not in cryptography.

How it works

Federation lets a user authenticate once at an identity provider and access a service provider on the strength of a SAML assertion the identity provider signs. The service provider's entire trust decision rests on verifying that signature correctly: which certificate signed it, which part of the XML the signature actually covers, and whether the verification function's return value was interpreted correctly. Every widely exploited SAML vulnerability in recent years is a failure in that verification code rather than in the cryptography underneath it.

The 2024 ruby-saml authentication bypass (CVE-2024-45409, disclosed September 2024) and the March 2025 signature-wrapping pair that followed it (CVE-2025-25291 and CVE-2025-25292) are all variations on the same bug: an attacker restructures the XML so the signature verification checks one part of the document while the application actually reads identity claims from a different, unsigned part, letting a validly signed assertion for one identity be reinterpreted as an assertion for another. The March 2025 patch for that pair was itself shown to be incomplete: CVE-2025-54572, disclosed in July 2025, is a parser-differential path the patch left open. The FortiWeb FortiCloud SSO bypass (CVE-2025-59719) is the same underlying flaw class, CWE-347 improper signature verification, in a different codebase. The August 2026 miniOrange WordPress plugin bypass followed the same pattern again in a third codebase: a PHP comparison treated OpenSSL's error return value as a successful verification, so a deliberately malformed signature was read as valid. Three unrelated products, three years, one recurring bug.

Why it works

Federation concentrates trust in the identity provider's signature and asks the service provider to do exactly one thing correctly: confirm that signature covers the claims it is about to trust, from the certificate it expects, before reading anything from the assertion. The control assumption that fails is that signature verification, being a well-defined cryptographic operation, is implemented uniformly correctly across service providers. It is not, because the verification sits in application code, not in the protocol itself, and application code has bugs: a boolean check on a tri-state return value, a canonicalization step that lets attacker-controlled XML alter what the signature actually covers, an algorithm-confusion path that accepts a downgrade the implementer never anticipated. SAML forgery is a validation bug dressed as a protocol failure, and it keeps recurring because every implementer writes that validation code separately.

How to detect it

SAML assertions where the XML structure contains multiple candidate elements for the same claim, particularly nested or duplicated NameID or Subject elements, which is the structural signature of a wrapping attempt.
Authentication events accepted from a service provider where the signing certificate does not match the one pinned for that identity provider relationship.
A spike in failed-then-succeeded SAML validation attempts from the same source in a short window, consistent with probing for a validation bypass.

Be honest about the limits: SAML libraries vary widely in how much of this validation detail they expose to application logs, and many deployments log only "authentication succeeded" with no record of what the signature actually covered. Detecting a forgery attempt after the fact frequently depends on library-level debug logging that is not enabled in production, which means the practical defense here is prevention through patching and configuration, not detection.

How to stop it

Patch SAML libraries and plugins promptly, and specifically re-verify the fix against every known wrapping variant, since the pattern across ruby-saml shows a first patch closing one path while leaving a related one open.
Pin the expected signing certificate for each identity provider relationship rather than trusting any certificate presented within the assertion.
Reject responses with unexpected or downgraded signature algorithms instead of falling through to a default acceptance path.
Audit signature verification code for exact-match comparison on any tri-state or non-boolean verification function return value, the specific bug class behind the miniOrange bypass.
Understand what SAML and its alternatives actually guarantee before relying on either; see SAML vs OIDC for where the protocols differ in how they carry and protect identity claims.

Seen in the wild

Sources

No enterprise ATT&CK sub-technique cleanly covers this mechanism. T1606.002 (Forge Web Credentials: SAML Tokens) presumes the adversary already holds a stolen IdP signing key and uses it to mint a valid, attacker-forged assertion from scratch, the Golden SAML pattern. The failures described in this brief are the opposite: the IdP's signature is genuine and its key was never touched, but the service provider's verification code fails to confirm that the signature actually covers the claims it reads, letting a validly signed assertion for one identity be reinterpreted as an assertion for another. One technique describes a stolen key; the other describes broken verification logic. Rather than force a mapping that does not fit, this brief cites no attack_mitre ID.

OASIS: SAML 2.0 specification