CVE-2024-20355Cisco SAML 2.0 mixes authorization domains

What broke

Cisco's SAML 2.0 implementation failed to separate authorization domains. An assertion or related token issued in one context could be accepted in another. Disclosed 22 May 2024. Cisco shipped product-specific fixes.

Why it matters

Audience and domain separation is how federation stays tenant-safe. This is the SAML version of CVE-2025-27371 (private_key_jwt audience ambiguity). Multi-tenant or multi-VPN Cisco deployments are the obvious victims: a login meant for environment A becomes a login for environment B.

What to do

• Apply the Cisco advisory that names CVE-2024-20355 for each product you run (ASA/FTD/ISE-adjacent SAML integrations first).
• Pin ACS URLs and entity IDs per environment. Shared SAML apps across prod and lab are how domain mix-ups become incidents.
• After patching, revoke long-lived VPN or admin sessions that were established through SAML.

After you patch

A SAML bypass means the service provider accepted an assertion it should have rejected, so anyone who exploited it authenticated as a real user and left a normal-looking log line.

• Revoke every session issued by the affected service provider, then rotate its session signing keys. Patching stops new forgeries and does nothing about sessions already minted.
• Audit administrative accounts and group memberships for changes during the exposure window. Signing in as an administrator is the point of this class, and adding a second account is the standard persistence step.
• Rotate the identity provider signing certificate if the flaw involved signature validation, and confirm the service provider pins the expected certificate rather than trusting anything in the assertion.
• Check your own implementation for the same class: exact-match comparison on verification results, rejection of unexpected signature algorithms, and audience and recency checks on every assertion. See SAML 2.0 and SAML vs OIDC.

Sources

• NVD: CVE-2024-20355
• Cisco PSIRT, May 2024