CVE-2025-25292

What it actually does

The flaw is an authentication bypass in ruby-saml caused by inconsistent XML parsing between ReXML and Nokogiri. A crafted SAML response can be interpreted differently during signature validation than during assertion consumption, enabling a SAML Signature Wrapping attack. In practical terms, the library may verify a legitimate signed XML element while the application later reads attacker-controlled assertion content from a different XML element, allowing the attacker to impersonate another user or alter SAML attributes without possessing the identity provider signing key.

Why it matters to the business

Applications that rely on vulnerable ruby-saml code for single sign-on may allow unauthorized logins, including impersonation of privileged users, if an attacker can submit crafted SAML responses. This can lead to account takeover, unauthorized access to sensitive applications, data exposure, fraudulent administrative actions, and loss of trust in SSO controls. Although this issue is not currently listed in CISA KEV and no exploit maturity is reported in the provided data, the EPSS score is high enough to justify prompt remediation, especially because authentication bypass flaws in SSO components can affect many downstream applications at once.

How an attack unfolds

An attacker targets an application that uses a vulnerable version of ruby-saml to process SAML authentication responses. The attacker obtains or observes the structure of a valid SAML response flow, then crafts an XML document containing both a signed element that will satisfy signature validation and a separate malicious assertion that will be interpreted by the application as the authenticated identity. Because ReXML and Nokogiri can construct different document trees from the same XML, the validation step and the assertion-reading step may operate on different elements. The attacker submits the crafted SAMLResponse to the service provider assertion consumer endpoint. If the vulnerable parser behavior is present and the application trusts the attacker-controlled assertion fields, the application creates a session for the forged identity or grants attacker-selected attributes, bypassing normal authentication.

How to fix it

Upgrade ruby-saml to a fixed release or source revision that includes the parser-differential fix. For the affected saml-toolkits/ruby-saml Git package, the provided fixed revision is 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2. Rebuild and redeploy all applications, containers, and services that vendor or bundle ruby-saml; do not rely only on updating a top-level Gemfile if the library is pinned, vendored, or embedded by a framework/plugin. Rotate SAML signing certificates only if compromise of the identity provider key is suspected; the primary fix is correcting SAML response parsing and validation. As compensating controls until patching is complete, restrict access to SAML assertion consumer endpoints where feasible, enforce strict SAML response validation, reject responses with duplicate assertions or multiple Signature elements unless explicitly expected, require signed assertions and signed responses according to provider policy, and add monitoring for anomalous SSO logins and unexpected privilege-bearing attributes.

How to confirm the fix worked

Confirm exposure by generating a complete dependency inventory for applications that process SAML and checking for ruby-saml from saml-toolkits/ruby-saml below the fixed Git revision 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2. Validate deployed artifacts as well as source manifests, including Gemfile.lock, gemspec files, container images, vendor/bundle directories, and packaged application dependencies. Confirm remediation by verifying the running application includes the fixed ruby-saml code, not merely an updated repository. Exercise SAML login regression tests after upgrading and include negative tests for XML Signature Wrapping patterns, such as duplicate Assertion elements, nested signed elements, multiple ds:Signature blocks, and mismatched signed versus consumed assertion IDs. Review application logs to ensure malformed or ambiguous SAML responses are rejected and do not create authenticated sessions.

Typical attack path

1. Identify an application using SAML SSO with ruby-saml in the authentication path.
2. Locate the SAML assertion consumer service endpoint that accepts SAMLResponse parameters.
3. Create or obtain a structurally valid SAML response template for the target service provider.
4. Craft an XML Signature Wrapping payload that contains a valid signed element and a separate attacker-controlled assertion.
5. Encode and submit the malicious SAMLResponse to the service provider endpoint.
6. Trigger parser differential behavior so signature validation succeeds on one XML structure while application logic consumes another assertion.
7. Receive an authenticated session as an impersonated user or with forged SAML attributes.
8. Use the resulting access to read data, perform privileged actions, or pivot to connected systems.

How to detect it

Look for evidence of crafted SAML responses submitted to assertion consumer service endpoints and for successful logins that immediately follow SAML parsing anomalies. Useful sources include web access logs, application authentication logs, SAML middleware logs, identity provider sign-in logs, service provider audit logs, reverse proxy/WAF logs, and retained SAMLResponse payloads if available. Focus on POST requests to SAML assertion consumer endpoints containing unusually large SAMLResponse values, XML with multiple Assertion elements, multiple ds:Signature elements, duplicate ID attributes, nested assertions, or mismatches between the signed assertion ID and the user/session ultimately created. Correlate SAML login events with identity provider records: a service provider login without a matching IdP-issued assertion, unexpected NameID values, changed role/group attributes, or administrative access from new IP addresses may indicate abuse. Also search application error logs for XML parsing inconsistencies, signature validation warnings, and rejected SAML responses around the same source IPs and user agents. Because exploitation may result only in a normal-looking authenticated session, behavioral review of post-login actions is important: privilege use, account changes, data exports, token creation, and access to sensitive administrative functions shortly after SSO login should be investigated.

• SAMLResponse=
• /saml/acs
• /users/auth/saml/callback
• /auth/saml/callback
• /sso/saml/acs
• /saml/consume
• <saml:Assertion
• <saml2:Assertion
• <Assertion
• <ds:Signature
• <Signature
• Duplicate ID
• duplicate ID
• multiple Assertion
• multiple assertions
• multiple ds:Signature
• Signature Wrapping
• XML Signature Wrapping
• Invalid Signature
• SAML response invalid
• SAMLResponse invalid
• SAML authentication failed
• ruby-saml
• OneLogin::RubySaml
• ReXML
• Nokogiri

What your security team should do

• Prioritize patching all internet-facing and high-value SAML service providers that use ruby-saml, because successful exploitation can directly bypass authentication.
• Inventory all applications, plugins, appliances, and internal services that include ruby-saml, including vendored copies and container images.
• Upgrade affected saml-toolkits/ruby-saml code to fixed commit 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2 or a release that contains that fix.
• Add detection for SAML responses with duplicate Assertion IDs, multiple Assertion elements, multiple ds:Signature elements, or signed elements that differ from the assertion used to establish the session.
• Review recent SSO authentication logs for unusual privilege changes, first-time logins, impossible travel, abnormal user-agent/IP combinations, and administrative sessions created through SAML.
• Harden SAML configuration by requiring strict audience, recipient, destination, issuer, NotBefore/NotOnOrAfter, InResponseTo, and signature validation checks.
• Ensure application-level authorization is not based solely on mutable SAML attributes without additional server-side checks.
• If suspicious SAML logins are found, revoke affected sessions, reset credentials where applicable, review account activity, and preserve SAML request/response logs for forensics.