Article Details

Federal frenzy to patch gaping GitLab account takeover hole. Warning comes exactly a year after the vulnerability was introduced. The US Cybersecurity and Infrastructure Security Agency (CISA) is forcing all federal agencies to patch a critical vulnerability in GitLab's Community and Enterprise editions, confirming it is very much under "active exploit." When CISA adds a vulnerability to its Known Exploited Vulnerabilities (KEV) list, it means all federal civilian executive branch (FCEB) agencies usually have a maximum of 21 days to fix the issue to prevent harmful attacks on the government. The name is somewhat of a giveaway, but security flaws added to the KEV list also mean they're known to be under active exploitation, necessitating a quick fix. The vulnerability, tracked as CVE-2023-7028, was disclosed by GitLab in January and was assigned a maximum 10 severity rating by the platform itself, which is a certified CVE Numbering Authority (CNA). The National Vulnerability Database (NVD) gave it a mere 7.5 score, however. At the time of disclosure, GitLab reported that the vulnerability had existed since May 2023, though there was no evidence of successful exploitation. The addition to CISA's KEV means this is now no longer the case, so get those patches installed pronto if they weren't sorted in January. The vulnerability is classed as an improper access control flaw, offering attackers a zero-click route to a full account takeover.  Starting in version 16.1.0, released May 1, 2023, a change was introduced that allowed users to reset their GitLab account passwords using a different email address, and a bug in the verification process opened up the vulnerability. A specially crafted HTTP request sends a password reset link to an unverified, attacker-controlled email address, enabling unauthorized account takeovers. Given the nature of GitLab's business, the obvious danger here is the vulnerability being abused by attackers to carry out software supply chain attacks – surreptitiously modifying source code to breach countless organizations. Russia with SolarWinds and North Korea with 3CX are two examples of adversarial nations with an appetite for supply chain attacks in recent years. Ransomware crews such as REvil with Kaseya and Cl0p with MOVEit are also no strangers to compromising software at the source, although CISA said it isn't aware of any ransomware-associated activity with the GitLab flaw yet. The upshot of all this is that admins who enabled some form of two-factor authentication (2FA) in GitLab are safe and unaffected by the vulnerability. And of course you enabled 2FA, didn't you? The following versions are vulnerable:  16.1 to 16.1.5 16.2 to 16.2.8 16.3 to 16.3.6 16.4 to 16.4.4 16.5 to 16.5.5 16.6 to 16.6.3 16.7 to 16.7.1 Shadowserver data showing number of vulnerable GitLab instances since the vulnerability's disclosure – click to enlarge Shadowserver's data shows that the number of publicly exposed GitLab instances has more than halved since the vulnerability's disclosure. There are currently 2,149 vulnerable GitLab environments, down from 4,652 in January, with the largest concentration in Europe and Asia. GitLab fixed the vulnerability in versions 16.5.6, 16.6.4, and 16.7.2, and also backported the patches for versions 16.1.6, 16.2.9, 16.3.7, and 16.4.5.