GitLab has released critical patch updates across its Community Edition (CE) and Enterprise Edition (EE) to address security vulnerabilities and bugs. The GitLab critical patch release includes vital updates for both GitLab Community Edition and Enterprise Edition. These updates are designed to address high-severity issues that could potentially compromise the integrity of the affected GitLab instances. The latest versions—17.3.2, 17.2.5, and 17.1.7—come with a comprehensive set of fixes and enhancements aimed at mitigating a variety of vulnerabilities.
All users running affected versions are strongly advised to upgrade their GitLab instances immediately to ensure protection against these vulnerabilities. Notably, GitLab.com has already been updated to include these critical fixes. For customers using GitLab Dedicated, no immediate action is required.
GitLab Critical Patch Fixes Multiple Vulnerabilities
GitLab employs two main types of patch releases to address security and bug-related issues: scheduled releases and ad-hoc critical patches. Scheduled releases occur twice a month on the second and fourth Wednesdays, while ad-hoc critical patches are issued in response to high-severity vulnerabilities. Details about these releases, including security fixes, are documented and made available to the public on GitLab’s issue tracker 30 days post-release.
The latest GitLab critical patch release includes fixes for several critical and high-severity vulnerabilities. These issues have been categorized based on their severity levels, ranging from critical to low. Below is a summary of the key vulnerabilities addressed.
All Major GitLab Vulnerabilities Fixed
A critical vulnerability allowed an attacker to trigger a pipeline as an arbitrary user under specific conditions. This issue affects all GitLab versions from 8.14 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2. It has been addressed in the latest release and is assigned CVE-2024-6678. Another high-severity issue involved incomplete input filtering that could have permitted code injection into a connected Cube server. This vulnerability affects versions from 16.11 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and has been assigned CVE-2024-8640.
A separate high-severity vulnerability allowed server-side request forgery, enabling attackers to make requests to internal resources using a custom Maven Dependency Proxy URL. This impacts versions from 16.8 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, with CVE-2024-8635 assigned to it. Additionally, sending a large glm_source parameter could result in a denial of service. This affects versions from 16.4 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and is listed under CVE-2024-8124.
A medium-severity issue allowed an attacker to use a victim’s CI_JOB_TOKEN to obtain their GitLab session token, impacting versions from 13.7 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, documented under CVE-2024-8641. Another medium-severity vulnerability allowed authenticated users to bypass variable overwrite protection via CI/CD template inclusion. This problem affects versions from 17.2 to 17.2.5 and 17.3 to 17.3.2, and is identified as CVE-2024-8311.
Guests could access the full source code of private projects using group templates, which affects versions from 11.2 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and is assigned CVE-2024-4660. Additionally, the IdentitiesController allowed attackers to link unclaimed provider identities when JWT authentication was configured, affecting versions from 16.9.7 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2.
Open redirects in the repo/tree/ and release permanent links endpoints could allow for account takeover by breaking the OAuth flow. These issues impact versions from 11.1 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and are assigned CVE-2024-4283 and CVE-2024-4612, respectively. Another medium-severity vulnerability allowed users with Admin Group Member permissions to escalate their roles. This affects versions from 16.6 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, documented as CVE-2024-8631.
Attackers could modify on-demand DAST scans to leak variables without appropriate permissions, affecting versions from 13.3 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and is listed under CVE-2024-2743. Another medium-severity issue involved the exposure of user passwords from repository mirror configurations, affecting versions from 15.10 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, identified as CVE-2024-5435.
Guest users could access commit information via the release Atom endpoint, contrary to permissions. This vulnerability affects versions from 17.0 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, documented as CVE-2024-6389. Additionally, dependency proxy credentials were logged in plaintext in GraphQL logs, affecting versions from 16.5 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, assigned CVE-2024-4472.
A low-severity issue allowed a crafted URL to trick a victim into trusting an attacker-controlled application. This impacts versions from 17.1 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, listed under CVE-2024-6446. Unauthorized group members could access group runners information, which affects versions from 16.7 to 17.1.7, 17.2 to 17.2.5, and 17.3 to 17.3.2, and is documented as CVE-2024-6685.
The new versions also include several bug fixes and improvements. Version 17.3.2 includes backports of OpenSSL updates, fixes for image resizing in RTE, API project listing issues, and improvements to Sidekiq stability and builder image usage. Version 17.2.5 features backports for asset image building, Google Cloud gems updates, and fixes for Geo-Replication details and job artifact queries. Version 17.1.7 includes backports for Geo-Replication view fixes, job artifact query timeouts, and updates to the builder images.
Conclusion
To ensure protection against recent vulnerabilities and bugs, it is strongly recommended that all users of GitLab Community Edition and Enterprise Edition update to one of the newly released versions. For detailed guidance on GitLab critical patch updates, please refer to the update page and Runner update page.
To stay updated on future GitLab critical patch releases, users can subscribe to GitLab’s patch release RSS feed or visit the Contact Us page for direct notifications. GitLab remains dedicated to security and stability, and these critical updates reflect the company’s ongoing commitment to upholding high-security standards across all its instances.