# ruby-saml auth bypass, incomplete fix of CVE-2025-25292

Source: https://startwithidentity.com/cves/cve-2025-54572/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

The March 2025 ruby-saml patches for [CVE-2025-25291](https://startwithidentity.com/cves/cve-2025-25291/) and [CVE-2025-25292](https://startwithidentity.com/cves/cve-2025-25292/) left a parser-differential path open. CVE-2025-54572 is that leftover: an attacker can still construct a [SAML](https://startwithidentity.com/glossary/saml/) response that verifies on one XML tree and authenticates as a different user on the other.

## Why it matters

Incomplete fixes are how signature-wrapping stays in production for a year. Teams that closed the March ticket and moved on were still impersonable. This is also why "we patched ruby-saml in Q1" is not an answer an auditor should accept in late 2025.

## What to do

- Confirm the running version is 1.18.1 or later, not "we patched in March."
- Re-test ACS handling with a known wrapping fixture after every library bump. Regression tests are how you catch the next incomplete fix, including [CVE-2025-66567](https://startwithidentity.com/cves/cve-2025-66567/).
- Rotate signing keys if the SP was reachable while on the incomplete patch.

## 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](https://startwithidentity.com/standards/saml-2-0/) and [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).

## Sources

- [NVD: CVE-2025-54572](https://nvd.nist.gov/vuln/detail/CVE-2025-54572)