With newly found XSS vulnerabilities affecting all prior GitLab EE versions, and user and notification email verification bypasses on the menu, GitLab users are strongly advised to make the jump to just released versions 13.0.1, 12.10.7, and 12.9.8.

In recent security releases enterprise users on newer versions tended to be the center of attention. Not this one, however, as this time the GitLab team (who just released v13 into the wild) came across issues affecting all previous versions. The first one tackled, for example, allows users to set an unverified email address as their notification email. 

The second issue seems a bit more severe because it can be used for denial of service attacks by uploading malicious artifacts and exhausting the platform’s memory. Central to the now mitigated issue is the project’s reverse proxy Workhorse, which was also part of a security flaw in the last security update. Another, an all versions-spanning vulnerability connected to the Repository Files API is restricted to the enterprise flavour and could lead to cross-site scripting attacks. 

This isn’t the only XSS vulnerability the release fixed, as GitLab was also informed about bugs in the static site editor and the metrics dashboards that could be used for such attacks. Both are mitigated in the recent versions. Users on versions newer than 12.0 can get rid of a DoS possibility on custom dashboards by updating their setups, those on 12.9 and later should look into the update to prevent client-side code injection via Mermaid payloads. 

GitLab 13.0.1, 12.10.7, and 12.9.8 also fixed an issue in CE/EE 12.5 and later, which lets users bypass the email verification process, and one in versions newer than 12.3 facilitating the use of OAuth Flow without email verification checks. Moreover, it prevents admins using Amazon EKS from accidentally disclosing their credentials to other administrators looking after the same GitLab instance, or Kubernetes cluster maintainers from sharing their cluster tokens.

If you now want to skip over to CVE and learn more about the severity of these new vulns, you still have to wait a bit, as CVE IDs for most of the issues haven’t been assigned yet. GitLab however promises to offer more details via its issue tracker in about a month, as is the norm for these releases.