Gitlab zero-click vulnerability under active exploitation
An account takeover vulnerability in GitLab needs your immediate attention.
A vulnerability that allows attackers to hijack GitLab accounts without any user interaction is under active exploitation. These so-called zero-click vulnerabilities are particularly dangerous because they are hard to detect and even harder to prevent, unless there is a patch available.
The Cybersecurity and Infrastructure Security Agency (CISA) has added the vulnerability to its catalog of known exploited vulnerabilities, which means Federal Civilian Executive Branch (FCEB) agencies need to remediate it by May 22, 2024. We urge everyone else to do this as soon as possible too.
GitLab is a web-based development platform that enables people working on a project to perform a wide range of tasks from project planning and source code management to progress monitoring and security.
The vulnerability, listed as CVE-2023-7028, is an issue in GitLab Community Edition (CE) and GitLab Enterprise Edition (EE) which allows user account password reset emails to be delivered to an unverified email address. The flaw affects all versions of the software from 16.1-16.1.5, 16.2-16.2.8, 16.3-16.3.6, 16.4-16.4.4, 16.5-16.5.5, 16.6-16.6.3, and 16.7 and 16.7.1.
The vulnerability allows a successful attacker to take over users’ accounts easily, without any interaction. To remediate the problem, users of self-managed instances must upgrade to a patched version following the specified upgrade path. The critical security release advisory by GitLab tells users to upgrade to 16.7.3, 16.6.5, 16.5.7, or newer to prevent the migration issue.
Do not skip upgrade stops as this could create instability. GitLab.com is already running the patched version.
A GitLab account takeover could have very serious consequences because it would allow an attacker to introduce unsafe code into a vendor’s codebase, or get access to an organization’s API keys.
The account takeover won’t work if the target has two-factor authentication (2FA) enabled, since the attacker will not be able to log in if they don’t have control of the second authentication factor.
GitLab supports as a second factor of authentication:
- Time-based one-time passwords (TOTP). When enabled, GitLab prompts you for a code when you sign in. Codes are generated by your one-time password authenticator (for example, a password manager on one of your devices).
- WebAuthn devices. You’re prompted to activate your WebAuthn device (usually by pressing a button on it) when you supply your username and password to sign in. This performs secure authentication on your behalf.
We don’t just report on vulnerabilities—we identify them, and prioritize action.
Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in check by using Malwarebytes Vulnerability and Patch Management.