In newly released versions 13.2.3, 13.1.6 and 13.0.12, repo management cum DevOps platform GitLab has pushed out a slew of security fixes to protect users from potential denial of service, access control and cross-site scripting vulnerabilities. Most of these don’t have CVE IDs yet, though additional information is expected to be released in the next 30 days.

The company “strongly recommends” you upgrade your installation to one of the new versions “immediately”, since quite a few of the issues tackled in them affect all previous GitLab versions. CVE-2020-13280 for instance could lead to memory exhaustion on lower resource machines due to excessive logging of invite email errors, while a not yet CVE listed bug allowed members of a parent group to still access transferred subgroups.

Users also reported an issue with hashes when adopting hexadecimal branch names, and a bug that skips the email verification step in GitLab’s OAuth authorisation code workflow, which affected all versions but is mitigated in the current releases. 

Speaking of OAuth, starting in GitLab 7.7, access grants seem to not have been revoked when a user revoked access to an application, which was corrected as well. Similar issues fixed in the release include overly permissive access in project sharing for GitLab 13.2 and later, and giving access to the profile/applications page to users who haven’t set up two-factor authentication, although it should be required (GitLab 8.4 and newer).

Looking into a classic vulnerability class, CVE-2020-13281 can lead to denial of service scenarios, because the project import feature didn’t perform size checks before decompressing data. It can be found in all versions newer than 8.9 and is remedied in the versions 13.2.3, 13.1.6 and 13.0.12. 

The GitLab team was also able to get rid of some stored cross-site scripting issues on the jobs site (affecting 13.0 and later) as well as in the issue reference number tooltip (EE 12.9 and later) and the issue list (10.8 and later). 

While GitLab.com users shouldn’t have to do anything at this point, those with free accounts and multi-factor authentication enabled are advised to take a minute to make sure they have an account recovery strategy in place. The company just announced that, starting August 15th, its support team won’t process MFA reset requests for free accounts anymore.

This in turn means that, depending on their primary authentication method, devs will have to say goodbye to their account if they, for example, forget to move their SSH key when using a new computer or lose their recovery keys. Approaches to reduce the chance of that happening include having some recovery codes on an external device or using hardware tokens where possible.

First reactions were mixed, with some asking for additional backup options. Chances that phone numbers as a way of verification will be added are slim though, since the approach is deemed problematic for security reasons. Merge and feature requests for alternative recovery methods are still welcome, nevertheless.