CVE-2024-45409

What it actually does

The Ruby SAML library fails to properly validate the XML signature on SAML Response and Assertion documents, allowing an attacker who possesses any legitimately signed document from the identity provider to substitute arbitrary content while preserving a valid signature.

Why it matters to the business

Attackers can obtain unauthorized access to any user account in affected applications, leading to account takeover, data exposure, and potential lateral movement within integrated systems; the vulnerability has been public for over two years with a moderate and stable exploit probability.

How an attack unfolds

An attacker first obtains a signed SAML Response or Assertion issued by the trusted IdP, then modifies the NameID, attributes, or other claims to impersonate any user, re-signs the document using the original signature value, and submits the forged response to the service provider, which accepts it due to the missing or incomplete signature verification check.

How to fix it

Upgrade ruby-saml to version 1.17.0 or 1.12.3; for GitLab installations, apply the commit f2789346710c02e9dae2b74802f4b9397538129e or later releases that incorporate the patched library. Validate that signature verification is enabled and strict after the upgrade.

How to confirm the fix worked

Confirm the installed ruby-saml gem version meets or exceeds 1.17.0 or 1.12.3, review application logs for successful SAML authentications after the upgrade, and test by replaying a legitimately signed document with modified claims to ensure rejection.

Typical attack path

1. Obtain a valid signed SAML document from the target identity provider through normal authentication or interception
2. Parse and alter the SAML Response or Assertion to change the subject identifier and any authorization attributes
3. Submit the modified document to the vulnerable service provider endpoint without triggering signature validation failure
4. Receive an authenticated session for the impersonated user account

How to detect it

Review web server and application logs for SAML Response submissions that result in authentication success shortly after the vulnerable library was in use; look for repeated or unusual NameID values that do not match expected user provisioning patterns.

What your security team should do

• Immediately upgrade all instances of ruby-saml and dependent applications such as GitLab to the fixed versions listed
• Audit recent authentication logs for any anomalous SAML logins that occurred before remediation
• Enforce strict signature and certificate validation settings in all SAML integrations
• Monitor EPSS score and any new exploit publications given the two-year public disclosure window