Unpacking CVE-2024-4985: Critical SAM

Technical Analysis of CVE-2024-4985

CVE-2024-4985 is a critical authentication bypass vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE) that allows an unauthenticated attacker to log in as any user on a vulnerable instance. This flaw, which carries a CVSS v3.1 score of 10.0, originates from the improper validation of Security Assertion Markup Language (SAML) assertions when certain configurations are active—specifically when the GitLab instance is configured to use SAML SSO with the extern_uid mapping and the omniauth-saml and ruby-saml gems are utilized. By crafting a malicious SAML response that omits or manipulates cryptographic signatures, an attacker can trick the application into associating their session with a target account, leading to full account takeover and potential administrative escalation.

SAML Integration and Authentication Architecture

To understand the mechanics of CVE-2024-4985, one must first examine how GitLab integrates with SAML for Single Sign-On (SSO). GitLab utilizes the Ruby-based OmniAuth middleware, specifically the omniauth-saml strategy, which in turn relies on the ruby-saml library to process XML-based SAML responses from an Identity Provider (IdP). In a standard SAML flow, the Service Provider (SP)—in this case, GitLab—receives a SAMLResponse via the user's browser after the user authenticates with the IdP.

The SAMLResponse contains assertions about the user, such as their identity (NameID) and attributes. Security in this protocol is heavily dependent on XML Digital Signatures (DSIG). The ruby-saml library is responsible for verifying that the response or the assertions within it are signed by the trusted IdP's private key. If the signature verification is bypassed or fails to execute, the SP has no way of verifying the authenticity of the claims made in the XML document.

The vulnerability exists because under specific conditions, GitLab's implementation failed to enforce the requirement for signed assertions. This falls under the broader category of broken authentication, where the logic governing identity verification is flawed. When a GitLab instance is configured with omniauth_saml, it expects a unique identifier (often the extern_uid) to map the SAML identity to a local GitLab user account. If an attacker knows the extern_uid or the email address associated with a high-privilege account, they can attempt to forge an unsigned assertion that GitLab will accept as valid.

Root Cause Analysis: The Ruby-SAML Failure

The core of the issue lies in how the ruby-saml gem handles the validation logic when the soft validation mode is enabled or when specific verification checks are skipped. In the context of CVE-2024-4985, the vulnerability is triggered when the SAML response is processed without a valid signature, yet the application logic continues to trust the attributes provided in the XML. Specifically, the vulnerability manifests when GitLab is configured to use the extern_uid as the primary mapping for users.

In vulnerable versions, the assertion consumer service (ACS) endpoint did not strictly validate that the incoming SAMLResponse was signed by the expected certificate. This allowed an attacker to construct a response that mirrored a legitimate IdP response but lacked the <ds:Signature> element. Because the validation logic was not "fail-closed" for unsigned responses in this specific configuration, the application proceeded to extract the NameID and map it to an existing user. For a detailed breakdown of the payload structure used to trigger this, researchers can refer to the exploit analysis of CVE-2024-4985.

Furthermore, the ruby-saml library versions prior to the patch contained logic that could be bypassed if the XML document was structured in a way that confused the parser regarding which elements were signed and which were not. This is a common pitfall in XML processing where the XPath expression used to find the signature does not strictly match the element being validated.

Attack Surface and Identification

The attack surface for CVE-2024-4985 is limited to GitLab instances where SAML SSO is enabled. This is not a default configuration, but it is extremely common in enterprise environments where GitLab is integrated with Okta, Microsoft Azure AD (Entra ID), or PingIdentity. Attackers can identify potentially vulnerable instances by performing reconnaissance on exposed GitLab endpoints. Using a tool like Zondex, an attacker can scan for GitLab instances that expose SAML-related metadata or provide a "Sign in with SAML" button on the login page.

Once a target is identified, the attacker needs to determine the extern_uid or the email address of the target user. In many organizations, the extern_uid is the same as the user's email or a standard employee ID, which can often be found through OSINT or by querying public APIs if the GitLab instance allows certain levels of information disclosure. If the attacker targets an administrator, the impact is a total compromise of the GitLab instance, including access to all repositories, CI/CD pipelines, and sensitive environment variables.

Component	Vulnerability Status	Requirement for Exploit
GitLab CE/EE	Vulnerable (12.2 - 17.0)	SAML SSO Enabled
ruby-saml Gem	Vulnerable (< 1.17.0)	Signature validation bypass
omniauth-saml Gem	Vulnerable (< 2.2.1)	Improper attribute mapping
extern_uid Mapping	Active	Necessary for account takeover

Exploitation Methodology

Exploitation of CVE-2024-4985 involves intercepting or initiating a SAML login flow and injecting a forged SAMLResponse. The attacker does not need a valid account on the IdP. Instead, they act as their own malicious IdP. The process typically follows these steps:

1. Target Selection: Identify a GitLab instance with SAML enabled and determine a target username or email.
2. Payload Crafting: Create a Base64-encoded XML document representing a SAMLResponse. This document must contain an Assertion element with a Subject matching the target user's extern_uid.
3. Signature Omission: Unlike a legitimate response, the attacker intentionally leaves the Signature block empty or removes it entirely. In a vulnerable configuration, the GitLab instance fails to reject the response despite the missing signature.
4. Request Submission: The attacker performs an HTTP POST request to the GitLab ACS endpoint (usually /users/auth/saml/callback) with the SAMLResponse parameter.
5. Session Establishment: GitLab processes the forged assertion, matches the extern_uid to the target user, and creates a session cookie for that user, effectively logging the attacker in.

The following example illustrates a simplified structure of a forged SAML assertion used in this context:

POST /users/auth/saml/callback HTTP/1.1
Host: gitlab.example.com
Content-Type: application/x-www-form-urlencoded

SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIElEPSJfYmFkLWlkIiBWZXJzaW9uPSIyLjAiPjxzYW1sOkFzc2VydGlvbiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iX2JhZC1hc3NlcnRpb24iPjxzYW1sOlN1YmplY3Q+PHNhbWw6TmFtZUlEPlRBUkdFVF9VU0VSX0lEPC9zYW1sOk5hbWVJRD48L3NhbWw6U3ViamVjdD48L3NhbWw6QXNzZXJ0aW9uPjwvc2FtbHA6UmVzcG9uc2U+&RelayState=...

In this example, the Base64 string decodes to an XML structure that identifies the user but lacks any cryptographic proof of origin. The vulnerability allows this unauthenticated input to dictate the identity of the session.

Remediation and Mitigation Strategies

The primary remediation for CVE-2024-4985 is upgrading GitLab to one of the patched versions. GitLab released security updates for multiple release tracks to address this issue. Organizations should immediately move to versions 17.0.1, 16.11.3, 16.10.6, or newer. These updates include patched versions of the ruby-saml and omniauth-saml gems that enforce strict signature verification.

For organizations unable to patch immediately, several mitigation steps can be taken to reduce the risk:

• Disable SAML SSO: Temporarily disabling SAML authentication and reverting to standard LDAP or local authentication (with MFA) will close the attack vector.
• Enforce Two-Factor Authentication (2FA): While the vulnerability bypasses the primary SAML authentication, if GitLab is configured to require 2FA for all users locally, the attacker may still be prompted for a second factor after the SAML bypass, provided the 2FA is managed by GitLab and not the IdP.
• Restrict Network Access: Using a security-focused proxy or VPN like VPNWG to restrict access to the GitLab instance to known corporate IP ranges can prevent external attackers from reaching the ACS endpoint.
• Monitor Logs: Review application_json.log and auth_json.log for suspicious SAML login events. Look for logins where the IdP metadata does not match expected values or where multiple login failures are followed by a successful login for a high-privilege account.

Organizations should also leverage attack surface management tools like Secably to identify all internet-facing GitLab instances and verify their versioning. Continuous scanning ensures that shadow IT or forgotten staging environments do not remain vulnerable to this exploit.

Impact of Configuration Specifics

It is important to understand that the severity of CVE-2024-4985 is highly dependent on the omniauth_saml configuration settings within the gitlab.rb file. Specifically, the args hash for SAML providers contains several flags that influence security. If security: { want_assertions_signed: true } was not explicitly set and enforced by the underlying library, the application was susceptible.

The patch introduced by GitLab ensures that even if these settings are misconfigured, the underlying library defaults to a more secure state that rejects unsigned assertions. This update also addresses a bypass where an attacker could provide a signed response for one user but an unsigned assertion for another within the same XML wrapper, a technique known as SAML Assertion Wrapping (XSW). This is similar to vulnerabilities seen in other platforms, such as those discussed in the analysis of CVE-2026-54419, where complex XML structures allow for logic bypasses.

Detection and Post-Exploitation Indicators

Detecting an exploitation attempt of CVE-2024-4985 requires deep inspection of the authentication logs. Because the exploit results in a "successful" login from the application's perspective, simple "access denied" monitoring will not suffice. Security teams should look for the following indicators of compromise (IoCs):

• Unexpected extern_uid Changes: Check for log entries where a user's extern_uid was modified or where a new user was created with a suspicious extern_uid via the SAML flow.
• Inconsistent IP Addresses: Successful SAML logins for administrative accounts originating from IP addresses that do not match the user's typical geographic location or corporate VPN range.
• Audit Log Discrepancies: GitLab's audit_json.log may show the "action": "authenticated" event with "with": "saml", but the preceding events might lack the typical IdP redirect logs if the attacker directly posted to the callback URL.

Furthermore, if an attacker gains administrative access, they will likely attempt to maintain persistence. This can include adding new SSH keys to the admin account, creating personal access tokens (PATs), or modifying CI/CD runners to execute malicious code. Reviewing the personal_access_tokens table in the GitLab database for recently created tokens is a critical post-incident step.

The vulnerability underscores the risks associated with complex authentication protocols like SAML when implemented via third-party libraries. While SAML provides robust SSO capabilities, the reliance on XML security—which is notoriously difficult to implement correctly—creates a significant attack surface. Proper configuration of the Service Provider, combined with rigorous library updates, is the only way to defend against such high-impact authentication bypasses.