It’s that time of the month when GitLab cranks out its usual slew of security fixes, but this time your API access token is at risk, so don’t wait too long to update.
Among the vulnerabilities mitigated in versions 13.7.2, 13.6.4, and 13.5.6 is a high severity issue that can be used to “steal a user’s API access token through GitLab Pages”.
The problem is caused by insufficient validation of authentication parameters in GitLab Pages, and affects all versions starting from GitLab 11.5. A CVE ID isn’t available yet, the issue is however said to score a 8.1 in the Common Vulnerability Scoring System (CVSS).
Installations newer than 13.7 have also been discovered to come with a medium severe vulnerability (CVE-2021-22166) that can allow an attacker to cause a Prometheus denial of service. The now fixed issue could be exploited by sending HTTP requests with a malformed method.
Another 5.3 (medium severity) on the CVSS the GitLab team was able to get rid of was incorrect headers “within a specific project page” that could be used to gain read access to project features restricted to members only. A CVE-ID wasn’t available at the time of writing; the problem can be found in all versions starting from v12.1.
Other than that GitLab’s security team found and fixed two regular expression denial of service issues in the NuGet API (v12.8+) and package uploads (v12.4+). While details on the former aren’t available yet, the latter is caused by the implementation of the regex used for package names, which “makes execution time have quadratic growth based on the length of the malicious input string”. Both score a 4.3 in the CVSS, making them medium severity issues as well.
GitLab “strongly recommends” upgrading to the latest version “as soon as possible” to keep installations safe. Since the update includes a database migration to reconfigure Trusted instance-wide OAuth applications as Confidential, the process might take a bit longer than usual.
The company also noted that, should you have problems following the update, this might be down to some clients not sending the client_ secret or using “the implicit flow during the OAuth authentication”. In that case some manual work might be needed to either adjust the process or make the app non-confidential, though if you go with the latter it is advised to mark it as non-trusted as well.
Users already on the 13.7.x series can skip v13.7.2 and jump straight to 13.7.3 if they wish, which just landed and updates Helm, fixes Canary Ingress weight issues in the UI, and includes a solution to a Job Trace polling issue that put a strain on Redis besides mitigating the vulnerabilities mentioned.