CVE-2025-25291

What it actually does

The vulnerability is an authentication bypass in ruby-saml caused by inconsistent XML parsing between ReXML and Nokogiri. A malicious SAML response can be structured so that signature validation is performed over one XML element while application identity data is read from a different element. This enables a SAML Signature Wrapping attack in which a validly signed assertion or response is embedded alongside attacker-controlled assertion content, potentially allowing the attacker to authenticate as another user without knowing that user's password.

Why it matters to the business

Applications that rely on vulnerable ruby-saml code for single sign-on may incorrectly trust forged SAML login responses, allowing unauthorized access to user accounts and protected business applications. The risk is highest for internet-facing SSO endpoints and applications where SAML assertions determine privileged access. Although this issue is not listed in CISA KEV and no mature public exploit is indicated, the EPSS score indicates meaningful exploitation likelihood, and the issue has been public for a long period, so delayed remediation increases exposure.

How an attack unfolds

An attacker targets an application using a vulnerable ruby-saml integration as its SAML service provider. The attacker obtains or reuses a legitimate SAML response structure, then crafts an XML document that abuses parser differences between ReXML and Nokogiri. The document contains signed XML content that passes signature checks, but also contains attacker-controlled assertion data that is interpreted as the authenticated user's identity by later processing. The attacker submits this crafted SAMLResponse to the application's Assertion Consumer Service endpoint. If the application accepts the response, it creates a session for the identity in the attacker-controlled assertion, resulting in authentication bypass and possible account takeover.

How to fix it

Upgrade ruby-saml to a fixed release or source revision that includes commit 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2. If ruby-saml is included transitively through SAML integrations such as Rails authentication middleware, update the parent package and verify that the resolved ruby-saml dependency is fixed. Rebuild and redeploy affected applications after updating dependencies. As defense in depth, require signed SAML responses or assertions as appropriate, validate issuer, audience, recipient, destination, InResponseTo, NotBefore, and NotOnOrAfter conditions, reject SAML messages with duplicate assertion IDs or multiple unexpected assertions, disable unsolicited SSO where not required, and ensure SAML processing uses a single consistent parser and strict schema/signature validation path.

How to confirm the fix worked

Confirm the deployed application resolves ruby-saml to a version or source revision containing commit 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2. Review Gemfile.lock, bundled gem metadata, container images, and vendored dependencies to ensure vulnerable ruby-saml code is no longer present. Exercise the SAML login flow after upgrade to verify legitimate SSO still succeeds and malformed or duplicated-assertion SAML responses are rejected. For source-based deployments, verify the fixed commit is present in the checked-out dependency. For runtime validation, test that SAML responses with multiple Assertion elements, duplicate IDs, or unsigned identity-bearing assertions are rejected and logged.

Typical attack path

1. Identify an application that uses ruby-saml for SAML single sign-on.
2. Locate the SAML Assertion Consumer Service endpoint, commonly an SSO callback or SAML consume URL.
3. Craft a SAML response that exploits XML parser differentials and signature wrapping behavior.
4. Include valid signed XML content that satisfies signature validation while placing attacker-controlled identity attributes in a differently parsed assertion structure.
5. Submit the crafted SAMLResponse to the service provider endpoint.
6. If accepted, obtain an authenticated application session as the targeted or attacker-selected identity.
7. Use the session to access application data or escalate privileges based on the compromised account's authorization.

How to detect it

Investigate both service provider application logs and identity provider audit logs. Look for SAML ACS endpoint requests containing unusually large or complex SAMLResponse values, XML parser errors, signature validation failures, duplicate Assertion elements, duplicate ID attributes, or multiple signatures in a single response. Correlate successful application logins against IdP-issued SAML events; a successful service provider session without a matching IdP authentication event is highly suspicious. Review web access logs for POST requests to SAML callback endpoints from unusual IP addresses, repeated failed SAML submissions followed by a successful login, and access to privileged accounts shortly after SSO anomalies. In application logs, search for ruby-saml validation warnings or errors around signature validation, digest validation, assertion conditions, audience restrictions, recipient checks, and XML parsing. For confirmed suspicious sessions, preserve the raw SAMLResponse if logged, session creation records, source IPs, user agents, IdP audit events, and subsequent authorization-sensitive actions.

• SAMLResponse=
• <saml:Assertion
• <saml2:Assertion
• <ds:Signature
• <dsig:Signature
• AssertionConsumerService
• /saml/acs
• /saml/consume
• /saml/callback
• /auth/saml/callback
• /users/auth/saml/callback
• /users/saml/auth
• Duplicate ID
• duplicate ID
• duplicate Assertion
• Invalid Signature
• Signature validation failed
• Digest mismatch
• Invalid SAML Response
• ruby-saml
• OneLogin::RubySaml
• REXML::ParseException
• Nokogiri::XML::SyntaxError
• InResponseTo
• NotOnOrAfter
• AudienceRestriction

What your security team should do

• Inventory all applications, services, and SSO integrations that use ruby-saml directly or through transitive Ruby authentication packages.
• Prioritize patching internet-facing SAML service provider endpoints and applications granting access to sensitive data or administrative functions.
• Upgrade ruby-saml to a fixed version or commit 48cc5b92e1dde8637a013dfd48cdf8ceadd499b2, then redeploy all affected application instances and containers.
• Search authentication and web logs for suspicious SAMLResponse submissions, especially failed signature validation events, XML parsing errors, duplicate assertions, and successful logins without corresponding identity provider events.
• Correlate service provider login events with identity provider audit logs to identify sessions accepted by the application without a matching IdP-issued assertion.
• Temporarily increase monitoring on SAML ACS endpoints and alert on anomalous POST volume, malformed XML, repeated SSO failures followed by success, or logins to privileged accounts from unusual IP addresses.
• Review SAML configuration hardening, including strict audience and recipient validation, signed assertion or response requirements, clock skew limits, and rejection of unsolicited SSO where unnecessary.
• Invalidate active sessions for high-risk applications after patching if suspicious SAML activity is found.