GitLab warns of critical zero-click account hijacking vulnerability

GitLab has released security updates for both the Community and Enterprise Edition to address two critical vulnerabilities, one of them allowing account hijacking with no user interaction.

The vendor strongly recommends updating as soon as possible all vulnerable versions of the DevSecOps platform (manual update required for self-hosted installations) and warns that if there is "no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, this means all types are affected.”

Vulnerability details

The most critical security issue GitLab patched has the maximum severity score (10 out of 10) and is being tracked as CVE-2023-7028. Successful exploitation does not require any interaction.

It is an authentication problem that permits password reset requests to be sent to arbitrary, unverified email addresses, allowing account takeover. If two-factor authentication (2FA) is active, it is possible to reset the password but the second authentication factor is still needed for successful login.

Hijacking a GitLab account can have a significant impact on an organization since the platform is typically used to host proprietary code, API keys and other sensitive data.

Another risk is that of supply chain attacks where attackers can compromise repositories by inserting malicious code in live environments when GitLab is used for CI/CD (Continuous Integration/Continuous Deployment).

The issue was discovered and reported to GitLab by security researcher ‘Asterion’ via the HackerOne bug bounty platform and was introduced on May 1, 2023, with version 16.1.0.

The following versions are impacted:

  • 16.1 prior to 16.1.5
  • 16.2 prior to 16.2.8
  • 16.3 prior to 16.3.6
  • 16.4 prior to 16.4.4
  • 16.5 prior to 16.5.6
  • 16.6 prior to 16.6.4
  • 16.7 prior to 16.7.2

The flaw was addressed in GitLab versions 16.7.2, 16.5.6, and 16.6.4, and the fix has also been backported to 16.1.6, 16.2.9, and 16.3.7.

GitLab says it has not detected any cases of active exploitation of CVE-2023-7028 but shared the following signs of compromise for defenders:

  • 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.
  • 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.

The second critical problem is identified as CVE-2023-5356 and has a severity score of 9.6 out of 10. An attacker could exploit it to abuse Slack/Mattermost integrations to execute slash commands as another user.

In Mattermost, slash commands allow integrating external applications into the workspace and in Slack they act as shortcuts for invoking apps in the mesasge composer box.

The rest of the flaws that GitLab fixed in version 16.7.2 are:

  1. CVE-2023-4812: High-severity vulnerability in GitLab 15.3 and later, enabling the bypassing of CODEOWNERS approval by making changes to a previously approved merge request.
  2. CVE-2023-6955: Improper access control for Workspaces existing in GitLab prior to 16.7.2, allowing attackers to create a workspace in one group associated with an agent from another group.
  3. CVE-2023-2030: Commit signature validation flaw impacting GitLab CE/EE versions 12.2 and onwards, involving the possibility of modifying the metadata of signed commits due to improper signature validation

For instructions and official update resources, check out GitLab’s update page. For Gitlab Runner, visit this webpage.

Related Articles:

Critical GitLab bug lets attackers run pipelines as any user

CISA says GitLab account takeover bug is actively exploited in attacks

Juniper releases out-of-cycle fix for max severity auth bypass flaw

Dev rejects CVE severity, makes his GitHub repo read-only

Exploit for critical Fortra FileCatalyst Workflow SQLi flaw released