CVE-2023-7028

What is GitLab?

GitLab is a complete DevOps platform providing source code management, CI/CD pipelines, issue tracking, and container registry in a single application. GitLab CE (Community Edition) and EE (Enterprise Edition) are self-hosted by software companies, technology organizations, government agencies, and enterprises — storing source code, infrastructure configurations, deployment pipelines, secrets (API keys, certificates), and development workflows. Account takeover on GitLab provides an attacker with access to all repositories owned by the compromised account, the ability to modify code and pipelines (supply chain attack potential), access to CI/CD secrets, and depending on permissions, access to deployment infrastructure.

Overview

CVE-2023-7028 is a critical improper access control vulnerability (CVSS 10.0) in GitLab CE/EE that allows an unauthenticated attacker to trigger a password reset email for any GitLab account to be sent to an arbitrary, unverified email address — enabling silent account takeover with no victim interaction required. The vulnerability affects all GitLab versions from 1.0 through 16.7.1, patched in 16.7.2. The scope changed (S:C) rating reflects that successful exploitation affects all repositories and resources accessible by the victim user — extending impact beyond the vulnerable GitLab instance to any downstream systems accessed via GitLab credentials.

Affected Versions

Technical Details

CWE-640 (Weak Password Recovery Mechanism for Forgotten Password). The GitLab password reset flow contains a vulnerability in how it validates email addresses during the reset request. When a user requests a password reset, GitLab is supposed to send the reset link only to the verified, primary email address on the account. A flaw in the validation logic allows an attacker to manipulate the password reset request so that the reset email is sent to an unverified (attacker-controlled) email address.

The attacker's process:

1. Identify the target GitLab account (by username or email, often publicly visible)
2. Submit a password reset request with the target account identifier, manipulated to route the reset email to the attacker's email address
3. Receive the password reset link at the attacker's address
4. Follow the link to set a new password on the victim's account
5. Log in as the victim — full account takeover

The victim receives no notification and is not prompted to take any action. Two-factor authentication (2FA), if enabled on the account, is a partial mitigating control — an attacker who completes the password reset still needs the 2FA code to log in.

Discovery

Discovered and reported to GitLab through their HackerOne bug bounty program. GitLab backported the fix to multiple older minor versions (16.1.6 through 16.6.4) reflecting the broad version range affected. Active exploitation was confirmed by May 2024, prompting the CISA KEV addition four months after the patch.

Exploitation Context

GitLab self-hosted instances are targets for supply chain attacks: an attacker who takes over a developer's account with access to production repositories or CI/CD pipelines can inject malicious code into software builds, steal deployment secrets, or modify infrastructure-as-code configurations. The CVSS 10.0 and no-authentication-required vector made this a high-priority target for threat actors scanning for unpatched GitLab instances following disclosure. Organizations that host source code for critical software (security tools, infrastructure components, customer-facing applications) are at elevated risk if developers' accounts are compromised via this vulnerability.

Remediation

1. Upgrade to GitLab 16.7.2, 16.6.4, 16.5.6, or the appropriate backport for your version branch.
2. For GitLab instances that could not be immediately patched: temporarily enable 2FA for all users — this doesn't prevent password reset via the vulnerability but requires the attacker to also steal the TOTP code before gaining access.
3. Review GitLab authentication logs for password reset requests submitted around the disclosure period (November 2023 to patch date) for unusual patterns — resets sent to unknown email addresses indicate exploitation.
4. Audit all admin and maintainer accounts for recent password resets, unfamiliar SSH keys added, or CI/CD variable modifications that could indicate post-compromise actions.
5. Enable GitLab's audit events log to capture all future password reset requests with source IP and requested destination address.
6. Require 2FA for all accounts with access to sensitive repositories or production deployment pipelines as a permanent policy.