The Impact of the GitLab Vulnerability | January 2024

GitLab Vulnerability Overview

Background Information

On January 11, 2024, GitLab released security updates to address multiple security flaws. GitLab is a cloud-based tool often used by software developers and engineers for version control as they collaborate and deploy code changes. The most serious flaw (CVE-2023-7028) received a maximum severity rating and may allow an attacker to take over legitimate user accounts. GitLab has released security patches, which should be applied as soon as possible.

Impact of the Vulnerability

Attackers may be able to exploit this vulnerability to take control of legitimate user accounts by sending password reset emails to an unverified email address. Within the affected versions, all authentication mechanisms are impacted. Additionally, users with two-factor authentication enabled are still vulnerable to password reset but not account takeover as their second authentication factor is required to successfully authenticate. Corvus has observed similar attacks on code repositories lead to high-profile incidents as the attackers are able to use stolen information to facilitate further access.

The vulnerability impacts all self-managed instances of GitLab Community Edition (CE) and Enterprise Edition (EE) using the versions listed below:

• 16.1 prior to 16.1.6

• 16.2 prior to 16.2.9

• 16.3 prior to 16.3.7

• 16.4 prior to 16.4.5

• 16.5 prior to 16.5.6

• 16.6 prior to 16.6.4

• 16.7 prior to 16.7.2

GitLab has addressed the issue in GitLab versions 16.5.6, 16.6.4, and 16.7.2, in addition to backporting the fix to versions 16.1.6, 16.2.9, 16.3.7, and 16.4.5.

Next Steps for GitLab Customers:

We encourage your organization to take the following steps to mitigate against potential attack:

1. Update to a patched version following GitLab’s upgrade path.

   1. Do not skip upgrade stops, as this could create instability.

   2. Note: 16.3.x is a required upgrade stop in the GitLab upgrade path.

2. Enforce Two-Factor Authentication for all GitLab accounts at your organization, especially users with elevated privileges such as administrator accounts. See here for instructions on how to do this.

3. While GitLab reports no known cases of exploitation, customers can review their logs for possible exploitation attempts:

   1. Check gitlab-rails/production_json.log for HTTP requests to the /users/password path with params.value.email consisting of a JSON array with multiple email addresses.

   2. Check gitlab-rails/audit_json.log for entries with meta.caller.id of PasswordsController#create and target_details consisting of a JSON array with multiple email addresses.