GitLab has addressed a critical severity vulnerability that could allow remote attackers to take over user accounts using hardcoded passwords.
The bug (discovered internally and tracked as CVE-2022-1162) affects both GitLab Community Edition (CE) and Enterprise Edition (EE).
This flaw results from static passwords accidentally set during OmniAuth-based registration in GitLab CE/EE. According to the team at GitLab, “a hardcoded password was set for accounts registered using an OmniAuth provider (e.g. OAuth, LDAP, SAML) in GitLab CE/EE versions 14.7 prior to 14.7.7, 14.8 prior to 14.8.5, and 14.9 prior to 14.9.2 allowing attackers to potentially take over accounts.”
At the time of writing, Gitlab says that no user accounts have been breached so far. However, with over 100,000 organizations using GitLab’s DevOps platform and with more than 30 million GitLab users worldwide, there is still the possibility that some accounts may have been compromised. GitLab says that it will continue to monitor the situation and added that it has already reset passwords for a limited number of GitLab.com users. Furthermore, versions 14.9.2, 14.8.5, and 14.7.7 for GitLab Community Edition (CE) and Enterprise Edition (EE) have been released to address the vulnerability. Users are advised to upgrade to the latest versions as soon as possible.
Passwords should be changed on a regular basis. When creating a new password, it is important to use a mixture of uppercase and lowercase letters, along with numbers and special characters. The longer the password, the more secure your account will be. GitLab users should also make sure that ‘Require 2FA’ is enabled. Multifactor authentication is always a more secure method of protecting a user’s account. If MFA is not feasible, users should disable ‘password authentication enabled for Git over HTTP(S)’. This will require users to use a personal access token, further securing the account.