SAML Attacks: Golden SAML, XML Signature Wrapping, SLO Abuse

Last updated: April 26, 2026

SAML (Security Assertion Markup Language) is the legacy enterprise SSO standard. It is still ubiquitous in B2B SaaS, government systems, and large-enterprise federated identity. SAML’s complexity — XML-based, multi-party trust, signature validation across nested elements — creates a security model that is famously hard to implement correctly. This article covers the modern SAML attack surface: XML Signature Wrapping (XSW), Golden SAML, IdP-initiated CSRF, and SLO abuse.

The mental model

SAML flow:

1. Service Provider (SP) redirects user to Identity Provider (IdP)
2. User authenticates with IdP
3. IdP returns a signed SAML Assertion (XML containing user identity and claims)
4. SP validates the signature, extracts identity, grants access

Attack surface lives in steps 3-4 — the signature validation and assertion parsing.

Attack 1: XML Signature Wrapping (XSW)

XML allows complex nested structures. A SAML response signs specific elements; the application reads identity from those elements. XSW exploits the gap when the signature-verification code looks at one place and the identity-extraction code looks at another:

• XSW1: Place the original assertion as a sibling of itself. Verifier validates one; parser reads the other.
• XSW2/3/4: Variations using XML namespaces, comments, or nested wrappers.
• XSW5/6/7/8: More creative wrappers exploiting specific XML libraries.

If the SP uses an XML library that resolves elements differently than the signature library expects (libxml2 vs Xerces, for instance), XSW lets an attacker forge identity.

Tools: SAMLRaider Burp extension. Captures a SAML response, lets you apply XSW manipulations, sends modified response. If the SP accepts, you have authentication bypass.

Attack 2: Golden SAML

If the attacker compromises the IdP signing certificate (private key), they can mint arbitrary SAML assertions for any user, on any service that trusts the IdP. The 2020 SolarWinds incident used this technique against Microsoft 365 / Azure AD federations.

The attack:

1. Attacker compromises IdP server (or its key store)
2. Extracts the SAML signing private key
3. Forges SAML assertions for high-value targets (CEO email, admin accounts)
4. Submits forged assertions to SPs that trust the IdP

Mitigations:

• HSM-backed IdP signing keys (key cannot be exported)
• Short certificate validity
• Detection of unusual SAML assertion patterns at the SP
• Certificate pinning where possible

Attack 3: SAML signature exclusion

Some SAML implementations have a flaw where if the signature element is removed, the response is treated as unsigned but still trusted. Test by stripping the signature from a captured response.

Attack 4: Comment injection in XML

XML allows comments; some parsers handle comments inconsistently. A SAML username field of [email protected]<!-->.attacker.com may parse as [email protected] in identity extraction but as the full string in signature validation. Result: the attacker proves they are [email protected].

Patched in most modern libraries. Test on legacy or custom implementations.

Attack 5: Cross-tenant assertion replay

If a SAML response from tenant A is submitted to tenant B, and B’s SP doesn’t verify the audience claim, B accepts the user as authenticated. Most modern SPs check audience; some don’t.

Attack 6: Single Logout (SLO) abuse

SAML Single Logout terminates sessions across all federated SPs. Implementation flaws:

• Logout requests forged by attackers force user to re-authenticate (DoS)
• Logout doesn’t invalidate the session — old session cookies still work
• Open-redirect via the logout URL parameter

Practical workflow

1. Capture SAML flow with Burp.
2. Use SAMLRaider to view assertion structure.
3. Test XSW variants 1-8.
4. Test signature exclusion (remove signature element).
5. Test comment injection in identity fields.
6. Test audience validation by replaying responses across tenants.
7. Test SLO redirect URI parameter for open-redirect.

Detection — what works

• SP-side audit logs — track every SAML response, flag failed validations, log malformed XML.
• IdP-side — track sign-in patterns; alerts on impossible-travel patterns and unusual user-claim combinations.
• HSM telemetry — monitoring of signing-key usage for Golden SAML detection.
• SIEM correlation — IdP login events correlated with subsequent SP access; gaps indicate SAML bypass.

The fix

• Modern SAML libraries (most are now patched against XSW).
• Signature validation must check the signed-elements list against the data being read.
• Audience validation enforced strictly.
• HSM-backed IdP keys for high-value federations.
• Migrate from SAML to OIDC where feasible — OIDC has a smaller attack surface.
• Certificate rotation procedures documented and tested.

How to find your next SAML bug

• SAMLRaider against every SP in your environment.
• Audit SAML library versions; old versions had documented XSW bugs.
• Check IdP key storage — file system or HSM?
• Test SLO endpoints for open-redirect.

Compliance angle

• RBI Cyber Framework — federated authentication for regulated entities; key management requirements.
• SEBI CSCRF — Q-RE / MII federations require documented controls including signing-key protection.
• DPDP §8(5) — SAML bypass leading to identity impersonation is a defensible-security failure.

The takeaway

SAML is legacy but ubiquitous. The attacks have been published for years; the defences are well-known. Test your SAML implementations with SAMLRaider before someone else does. For new federations, OIDC is the simpler and safer choice. For existing SAML, library updates plus audience validation closes the most common bypasses.