CVE-2026-1168 in GitLab
Summary
by MITRE • 09/16/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.4.6 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an unauthenticated user to cause denial of service due to improper resource allocation limits in the GraphQL complexity calculation logic.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within GitLab Community Edition and Enterprise Edition represents a significant availability risk stemming from flaws in the GraphQL query processing subsystem. This issue affects multiple release branches, specifically impacting versions prior to 19.1.8 for releases starting at 18.4.6, as well as versions before 19.2.6 and 19.3.2. The core of the problem lies in the GraphQL complexity calculation logic, which is designed to estimate the computational cost of incoming queries to prevent excessive resource consumption. Under specific conditions, this mechanism fails to correctly enforce limits on query complexity, allowing an unauthenticated actor to construct requests that bypass these safeguards. Because authentication is not required for exploitation, the attack surface is broadened significantly, as any external entity with network access to the GitLab instance can attempt to trigger the flaw without needing valid credentials or prior interaction with the system.
From a technical perspective, GraphQL APIs often employ complexity scoring systems where each field in a query contributes to a total score based on predefined weights and nesting depths. The intended behavior is for the server to reject queries that exceed a configured threshold, thereby protecting backend resources from being overwhelmed by deeply nested or excessively broad requests. In this instance, improper resource allocation limits within the calculation logic mean that certain malformed or specifically crafted GraphQL operations are evaluated as having low complexity while actually consuming disproportionate amounts of CPU and memory during execution. This discrepancy allows an attacker to send a sequence of seemingly lightweight queries that cumulatively exhaust system resources. The failure is not in the parsing phase but rather in how the calculated cost maps to actual resource consumption, creating a vector for denial of service through inefficient handling of complex data structures or recursive relationships within the GraphQL schema.
The operational impact of this vulnerability centers on availability and service stability. An unauthenticated attacker can leverage this flaw to cause a denial of service by saturating server resources such as CPU cycles, memory, or database connections. This does not necessarily involve data exfiltration or unauthorized access to sensitive information but rather degrades the performance of the GitLab instance for all users. In severe cases, continuous exploitation could lead to complete system unresponsiveness, requiring manual intervention or restarts by administrators to restore service. For organizations relying on GitLab for critical development workflows and CI/CD pipelines, such instability can result in significant productivity losses and potential breaches of service level agreements if the platform becomes unavailable during peak usage times.
This vulnerability aligns with CWE-787 Improper Access Control when considering the bypass of intended resource limits, though it is more accurately categorized under CWE-400 Uncontrolled Resource Consumption or CWE-611 Information Exposure Through Query Fields depending on the specific manifestation. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1499 Endpoint Denial of Service and potentially T1529 System Shutdown Reboot if the exhaustion leads to a crash requiring restart. Mitigation strategies primarily involve upgrading GitLab CE or EE to versions 19.1.8, 19.2.6, or 19.3.2 respectively, where these resource allocation limits have been corrected in the GraphQL complexity calculation logic. Until upgrades are performed, administrators should consider implementing network-level rate limiting for GraphQL endpoints and restricting access to GitLab instances via firewalls or reverse proxies that can detect and block anomalous traffic patterns indicative of denial-of-service attempts. Additionally, monitoring system metrics such as CPU usage and memory consumption during API requests can help in identifying potential exploitation activities before they cause significant disruption.