GitLab Patches Critical Vulnerabilities

GitLab issued security updates for three versions of GitLab Community Edition and Enterprise Edition software that address, among other flaws, a critical hard-coded password bug.

The cloud-hosted software version control service released versions 14.9.2, 14.8.5, and 14.7.7 of its self-hosted CE and EE software, fixing one “critical” security vulnerability (CVE-2022-1162), as well as two rated “high,” nine rated “medium,” and four rated “low

It appears from the changed files  the password.rb  module generated a fake strong password for testing by concatenating “123qweQWE!@#” with a number of “0”s equal to the difference of  User.password_length.max, which is user-set, and DEFAULT_LENGTH, which hard-coded with the value 12.

So if configured its own instance of GitLab to accept passwords of no more than 21 characters, it looks like that an account takeover attack on that GitLab installation could use the default password of “123qweQWE!@#000000000” to access accounts created via OmniAuth.

The bug, with a 9.1 CVSS score, was found internally by GitLab and the fix has been applied to the company’s hosted service already, in conjunction with a limited password reset.

GitLab has also released a script with a “use at your own risk” warning to automatically reset user passwords in self-managed GitLab instances.

Also in addition to above, a stored XSS vulnerability (CVE-2022-1175) arising from improper input sanitation in notes. This allowed an attacker to exploit cross-site scripting by injecting HTML.

CVE-2022-1190, which enables a stored XSS attack by putting code in multi-word milestone references in issue descriptions, comments, and so on.

These last two CVEs are both rated high severity, with CVSS scores of 8.7. While the medium and low severity bugs may not as worrisome, GitLab is keen to have everyone update regardless.

GitLab claims to have 30 million registered users and a million active license users, with more than 100,000 organizations using the firm’s software.