CVE-2025-25292 - How ruby-saml’s XML Parser Difference Led to SSO Authentication Bypass

ruby-saml is a popular Ruby library for supporting Security Assertion Markup Language (SAML) single sign-on (SSO). Widely used in Ruby applications, it’s trusted by many projects and organizations for secure authentication. In early 2025, a serious vulnerability was found—a nuanced issue involving XML parsing that allowed attackers to defeat authentication checks. This flaw, tracked as CVE-2025-25292, could let smart attackers slip past your login wall entirely. Here’s how it happened, how it can be exploited, and how to stay safe.

Summary of the Vulnerability

- Product: ruby-saml

Patched Versions: 1.12.4 and 1.18.

- CVE: CVE-2025-25292 at GitHub Advisory Database *(placeholder, update with actual link when available)*

How Signature Wrapping Attacks Work in ruby-saml

SAML works by exchanging XML-formatted authentication messages between Identity Providers (IdP) and Service Providers (your app). The critical security check is validating the digital signature on the message, proving it was issued by a trusted source. If the XML signature can be “wrapped” in a tricky structure, the library might check a valid signature on a harmless element, while using attacker-controlled data elsewhere.

The catch: If different XML parsers interpret the structure differently, the application might not verify what it thinks it’s verifying.

ruby-saml historically supported both

- REXML: A pure-Ruby XML parser.
- Nokogiri: A fast C-backed parser.

Both should parse XML to the same structure, but in edge cases, differences appear. In this case, a specially crafted SAML assertion XML could look legitimate to one parser but very different to the other. Each parser might extract and verify different parts of the XML, letting attackers sneak unsigned assertions past the signature check.

Let’s see a simple code example to show how this can happen

require 'ruby-saml'

def handle_saml_response(saml_response_xml)
  # The parser might be REXML or Nokogiri, depending on the config!
  response = OneLogin::RubySaml::Response.new(saml_response_xml)

  if response.is_valid?
    puts "User authenticated! User email: #{response.name_id}"
  else
    puts "Authentication failed."
  end
end

An attacker sends a SAML response like this (simplified for clarity)

<Response>
  <Assertion ID="A1">
    <!-- Unsigned, attacker-controlled assertion -->
    <Subject>
      <NameID>attacker@example.com</NameID>
    </Subject>
  </Assertion>
  <Signature>
    <!-- Valid signature over a different, innocuous assertion! -->
  </Signature>
</Response>

Check the Signature against the “good” assertion (signed by the IdP).

- Accept the attacker’s assertion for actual authentication (since it came first or last in the structure).

Result: Authentication is bypassed! The attacker logs in as any user they choose, despite not having a real SAML assertion.

How Was It Fixed?

- Patched Versions: 1.12.4 (v1), 1.18. (v2) of ruby-saml make the XML parsing consistent and hardened against signature wrapping tricks.
- What changed: The library no longer trusts the first/last assertion blindly and includes robust logic to bind signatures to the correct assertion, no matter which parser is used.
- Reference: ruby-saml Security Release Notes *(see releases for security fixes related to CVE-2025-25292)*

Am I Affected?

If you use ruby-saml prior to 1.12.4 or 1.18., you are at risk—even if your SAML configuration is correct. The attack is complex, but feasible, and can happen with any SAML Identity Provider.

Check your Gemfile.lock:

grep ruby-saml Gemfile.lock

Validate SAML assertion structures in tests.

## Learn More / References

- ruby-saml GitHub Repository
- ruby-saml Security Release Notes
- Signature Wrapping Attacks Explained
- OWASP SAML Security Cheat Sheet
- CVE-2025-25292 (NVD) *(link may be updated)*

Conclusion

CVE-2025-25292 highlights a hidden risk in relying on multiple XML parsers. Even trusted libraries can slip up in edge cases. If you use ruby-saml, patch now. Always keep your dependencies up-to-date and review security advisories regularly. SAML security is hard—don’t let attackers take the easy way in.


Have you checked your apps for this vulnerability?
Drop a comment or reach out on GitHub if you have questions or need help with SAML hardening!

Timeline

Published on: 03/12/2025 21:15:42 UTC
Last modified on: 03/20/2025 14:15:24 UTC