CVE-2026-77801 in GitLab
Summary
by MITRE • 08/26/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.8 before 19.1.7, 19.2 before 19.2.5, and 19.3 before 19.3.1 that, under certain conditions, could have allowed an authenticated user to cause a denial of service affecting background job processing, due to missing object count limits.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in GitLab Community Edition and Enterprise Edition represents a significant reliability risk for platforms relying on asynchronous task execution. This flaw affects all versions from 12.8 up to but not including 19.1.7, as well as the specific release windows of 19.2 before 19.2.5 and 19.3 before 19.3.1. The core issue stems from a lack of enforcement on object count limits within certain background job processing mechanisms. In modern web applications like GitLab, many operations such as repository mirroring, CI/CD pipeline execution, or notification dispatching are offloaded to background workers to prevent blocking the main application thread. These jobs often process collections of data objects, and without proper constraints on the size of these collections, a malicious actor can exploit this oversight to trigger resource exhaustion.
From a technical perspective, the absence of object count limits allows an authenticated user to submit requests that result in the creation or processing of excessively large datasets within background jobs. When such a job is queued, it consumes memory and CPU resources proportional to the number of objects processed. By crafting inputs that maximize this volume, an attacker can cause these workers to become unresponsive or crash due to out-of-memory errors or excessive load. This effectively leads to a denial of service condition where legitimate background tasks are delayed, stalled, or failed entirely. The impact is particularly severe because GitLab relies heavily on its sidekiq-based job queue for critical functionality; disrupting this pipeline can halt code reviews, block deployments, and prevent issue tracking updates from being processed in real time.
The operational impact of this vulnerability extends beyond simple service interruption. It undermines the availability guarantees provided by the platform, potentially causing data inconsistencies if jobs are interrupted mid-execution without proper rollback mechanisms. Furthermore, because the attack requires authentication, it targets users who have already been granted access to the system, making detection more difficult compared to unauthenticated attacks. The attacker does not need elevated privileges beyond standard user rights in many configurations, which broadens the potential threat surface. This aligns with Common Weakness Enumeration (CWE) category CWE-400: Uncontrolled Resource Consumption, specifically highlighting how insufficient input validation regarding collection sizes can lead to resource exhaustion.
In terms of tactical classification within the MITRE ATT&CK framework, this vulnerability facilitates actions consistent with Impact tactics, particularly Denial of Service against infrastructure or applications. While it does not directly compromise confidentiality or integrity in the traditional sense, its effect on availability is profound. The exploitation vector involves authenticated interaction with the application interface to trigger the flawed background job logic. This underscores the importance of implementing defense-in-depth strategies where even trusted users are subject to strict resource quotas and rate limiting policies at both the API level and the underlying worker configuration.
Mitigation for this issue requires immediate upgrading to a patched version of GitLab, specifically 19.1.7 or later for the older branch, 19.2.5 or later for the 19.2 series, and 19.3.1 or later for the 19.3 series. For organizations unable to upgrade immediately due to operational constraints, implementing strict rate limiting on API endpoints that trigger background jobs can provide a temporary layer of protection. Additionally, monitoring worker memory usage and job queue depth through GitLab's observability tools can help detect anomalous patterns indicative of exploitation attempts. Administrators should also review their sidekiq configuration to ensure appropriate concurrency limits are set based on available hardware resources, thereby reducing the blast radius if such an attack occurs in unpatched environments.