GitLab, a leading DevOps platform, has recently issued critical security updates for its Community Edition (CE) and Enterprise Edition (EE) to address multiple high-severity vulnerabilities. These flaws could potentially allow unauthenticated attackers to crash self-managed GitLab instances, leading to service disruptions and data loss. Administrators are strongly advised to upgrade to the latest versions—18.4.1, 18.3.3, and 18.2.7—to mitigate these risks.
Understanding the High-Severity Vulnerabilities
Two of the most critical vulnerabilities addressed in this release are:
1. CVE-2025-10858: This vulnerability, with a CVSS score of 7.5, allows unauthenticated attackers to perform Denial-of-Service (DoS) attacks by sending specially crafted JSON payloads to specific endpoints, such as `/api/v4/projects/:id/uploads`. Exploiting this flaw can exhaust CPU and memory resources, rendering the Rails web server unresponsive. This issue affects all versions prior to 18.4.1, 18.3.3, and 18.2.7.
2. CVE-2025-8014: Also carrying a CVSS score of 7.5, this vulnerability involves unbounded GraphQL queries. Attackers can construct deeply nested or overly complex queries against the `/api/graphql` endpoint, bypassing internal query cost thresholds and triggering a crash loop in the unicorn worker pool. This flaw impacts self-managed GitLab instances and internal graphs, potentially disrupting Continuous Integration/Continuous Deployment (CI/CD) pipelines.
Additional Medium-Severity Vulnerabilities
Alongside the high-severity issues, GitLab has addressed several medium-severity vulnerabilities:
– CVE-2025-9958: With a CVSS score of 6.8, this vulnerability allows information disclosure in virtual registry configurations. Low-privileged users can access sensitive registry tokens via the `/api/v4/registry/repositories/:id` endpoint.
– CVE-2025-7691: This flaw, scoring 6.5 on the CVSS scale, enables privilege escalation. Developers with group-management permissions can elevate their privileges through crafted API calls to `/api/v4/groups/:group_id/members`, bypassing role checks in the Enterprise Edition backend.
Impact and Recommendations
These vulnerabilities pose significant risks, including potential service disruptions, unauthorized access, and data breaches. Administrators of self-managed GitLab instances are urged to upgrade to the latest patched versions—18.4.1, 18.3.3, and 18.2.7—immediately. GitLab Dedicated customers are already on the patched versions and do not require further action.
Upgrade Instructions
To upgrade your GitLab instance:
1. Backup Your Data: Before initiating the upgrade, ensure that you have a complete backup of your GitLab instance to prevent data loss in case of unforeseen issues.
2. Review the Official Update Guide: GitLab provides a comprehensive update guide that outlines the steps for upgrading your instance. This guide includes instructions for different installation methods, such as Omnibus packages and source installations.
3. Use Omnibus Packages for Seamless Upgrades: If you’re using Omnibus packages, you can leverage the `/etc/gitlab/skip-auto-reconfigure` flag to apply the patch with zero downtime in multi-node deployments. This approach ensures that your services remain available during the upgrade process.
4. Verify the Upgrade: After completing the upgrade, verify that your GitLab instance is functioning correctly. Check the logs for any errors and ensure that all services are running as expected.
Conclusion
The prompt application of these security patches is crucial to maintaining the integrity and availability of your GitLab instances. By addressing these vulnerabilities, GitLab continues to demonstrate its commitment to providing a secure and reliable platform for its users.
