Critical ruby-saml Vulnerabilities Allow Attackers to Bypass Authentication

A critical security vulnerability has been identified in the ruby-saml library, a popular tool used for Single Sign-On (SSO) via Security Assertion Markup Language (SAML) on the service provider side.

The vulnerabilities, designated as CVE-2025-25291 and CVE-2025-25292, allow attackers to bypass authentication and conduct account takeover attacks if they possess a valid signature created with the targeted organization’s key.

The ruby-saml library is widely used in various applications and products, including notable projects like GitLab.

- Advertisement -

While GitHub does not currently use this library for authentication, the platform recently evaluated its adoption following the discovery of vulnerabilities in its own SAML implementation.

This decision to reassess ruby-saml was prompted after a significant authentication bypass flaw was disclosed in October 2024 (CVE-2024-45409).

Background and Discovery

The vulnerabilities were discovered during a comprehensive security review by GitHub’s Security Lab and bug bounty researchers.

The review was initiated after GitHub decided to reconsider using ruby-saml due to the previously disclosed vulnerabilities in their own implementation.

The research identified that ruby-saml uses two different XML parsers, REXML and Nokogiri, during the signature verification process.

This dual-parser setup introduced a potential for parser differentials, where REXML and Nokogiri could be tricked into retrieving different signature elements, leading to a possible authentication bypass.

The discovery process involved several stages:

1. Identifying the Use of Multiple Parsers: The code review revealed that REXML and Nokogiri were both used during signature verification.
2. Assessing Exploitability: Researchers evaluated whether the parser differential could be exploited.
3. Finding a Parser Differential: It was determined that the parsers could indeed be tricked into seeing different signatures.
4. Creating a Full Exploit: The final step involved leveraging the parser differential to create an authentication bypass exploit.

Code Snippets Showing Parser Differential

Here is a look at how the signature elements are retrieved using both REXML and Nokogiri:

# Retrieving the Signature Element with REXML

sig_element = REXML::XPath.first(

  @working_copy,

  "//ds:Signature",

  {"ds"=>DSIG}

)

# Retrieving the Signature Element with Nokogiri

noko_sig_element = document.at_xpath('//ds:Signature', 'ds' => DSIG)

In the validate_signature method of xml_security.rb, the signature value is extracted from the sig_element obtained with REXML:

base64_signature = REXML::XPath.first(

  sig_element,

  "./ds:SignatureValue",

  {"ds" => DSIG}

)

signature = Base64.decode64(OneLogin::RubySaml::Utils.element_text(base64_signature))

Meanwhile, the SignedInfo element is extracted from the noko_sig_element obtained with Nokogiri:

noko_signed_info_element = noko_sig_element.at_xpath('./ds:SignedInfo', 'ds' => DSIG)

canon_string = noko_signed_info_element.canonicalize(canon_algorithm)

How SAML Responses Are Validated

SAML responses are used to transport user information from the identity provider (IdP) to the service provider (SP) in XML format.

The response includes a signature that must be verified to prevent tampering. The verification involves canonicalizing and comparing the SignedInfo and DigestValue elements.

Exploiting the Parser Differential

Ahacker1, a participant in GitHub’s bug bounty program, successfully created an exploit by leveraging the parser differential.

This was followed by another exploit developed using different methods. Both exploits enabled an attacker to bypass authentication if they had access to a valid signature from the targeted organization.

This could be obtained from previously signed assertions or responses from other users or even publicly accessible metadata.

Example of an XML Signature

An actual Signature element from a SAML response might look like this (namespace information removed for clarity):

<Signature>

    <SignedInfo>

        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

        <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

        <Reference URI="#_SAMEID">

            <Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms>

            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />

            <DigestValue>Su4v[..]</DigestValue>

        </Reference>

    </SignedInfo>

    <SignatureValue>L8/i[..]</SignatureValue>

    <KeyInfo>

        <X509Data>

            <X509Certificate>MIID[..]</X509Certificate>

        </X509Data>

    </KeyInfo>

</Signature>

Impact and Recommendations

Users of the ruby-saml library are advised to update to version 1.18.0 as soon as possible to mitigate these vulnerabilities.

Projects or libraries that utilize ruby-saml, such as omniauth-saml, should also update to a version that references a fixed version of ruby-saml.

The discovery of these vulnerabilities underscores the importance of thorough security audits and bug bounty programs in identifying and addressing critical issues before they can be exploited by malicious actors.

As cybersecurity threats evolve, maintaining up-to-date libraries and frameworks is crucial to preventing exploitation and ensuring the security of both users and organizations.

In summary, the vulnerabilities in ruby-saml highlight the ongoing challenges in securing SSO systems but also demonstrate how collaborative efforts between researchers and companies can lead to better security outcomes.

The security community will continue to monitor these issues and ensure that libraries like ruby-saml remain secure against emerging threats.

Are you from SOC/DFIR Teams? – Analyse Malware Incidents & get live Access with ANY.RUN -> Start Now for Free.