GitLab warns zero-click vulnerability could lead to account takeovers
GitLab has issued a warning about a critical vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). GitLab is an online DevOps platform that allows developers to collaborate on creating software. Organizations have a choice to install GitLab on their own server(s) or under GitLab’s control on GitLab.com.
The vulnerability allows a successful attacker to easily take over users’ accounts without any interaction. To remediate the problem, users of self-managed instances must upgrade to a patched version following the specified upgrade path. Do not skip upgrade stops as this could create instability. GitLab.com is already running the patched version.
The Common Vulnerabilities and Exposures (CVE) database lists publicly disclosed computer security flaws. As we can see from the description in the database, the root of the problem is that it’s possible to direct password reset emails to unverified email addresses.
CVE-2023-7028 (CVSS score 10 out of 10): an issue has been discovered in GitLab CE/EE affecting all versions from 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, and 16.7 prior to 16.7.2 in which user account password reset emails could be delivered to an unverified email address.
A GitLab account takeover can have serious consequences since the attacker could introduce unsafe code or get access to an organization’s API keys.
The account takeover won’t work if the target has 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.
Another critical vulnerability is listed as CVE-2023-5356 (CVSS score 9.6 out of 10): incorrect authorization checks in GitLab CE/EE from all versions starting from 8.13 before 16.5.6, all versions starting from 16.6 before 16.6.4, all versions starting from 16.7 before 16.7.2, allows a user to abuse Slack/Mattermost integrations to execute slash commands as another user.
Instructions on how to enable 2FA for GitLab can be found on GitLab docs. Enabling 2FA is recommended, even if you upgrade immediately.
GitLab states it has not detected any abuse of this vulnerability on platforms managed by GitLab, including GitLab.com and GitLab Dedicated instances.
We don’t just report on vulnerabilities—we identify them, and prioritize action.
Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in tow by using ThreatDown Vulnerability and Patch Management.
