CVE-2025-14871 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 deficiencies in input validation and resource management mechanisms specifically located within the GraphQL API layer. This flaw affects multiple release branches, including versions prior to 19.1.8 for the 18.x series, prior to 19.2.6 for the 19.2 branch, and prior to 19.3.2 for the 19.3 branch. The core of the issue lies in the GraphQL complexity calculation logic, which is designed to estimate the computational cost of incoming queries before execution. This mechanism serves as a critical safeguard against resource exhaustion by preventing clients from submitting excessively complex or deeply nested requests that could overwhelm server resources. However, due to improper implementation of these allocation limits under specific conditions, an attacker can craft malicious GraphQL payloads that bypass these safeguards.
From a technical perspective, the flaw allows for denial of service through unauthenticated access vectors. Because the vulnerability does not require authentication, any external actor on the internet can target the GitLab instance without needing valid credentials or prior interaction with the system. The attack likely involves constructing queries that exploit edge cases in how complexity scores are calculated or aggregated. By sending requests that appear benign to standard parsers but trigger disproportionate resource consumption during execution, an attacker can cause the server to consume excessive CPU cycles, memory, or database connections. This leads to service degradation for legitimate users and potentially complete unavailability of the GitLab instance if the load is sustained or sufficiently intense.
The operational impact of this vulnerability extends beyond simple downtime. For organizations relying on GitLab for continuous integration and deployment pipelines, source code management, and collaborative development workflows, an outage disrupts critical business operations. Developers may be unable to push code, review pull requests, or trigger automated builds, leading to delays in software delivery cycles. Furthermore, the unauthenticated nature of the exploit means that even instances with strict firewall rules protecting administrative interfaces remain vulnerable if the GraphQL endpoint is exposed on standard web ports. This highlights a common challenge in modern API-driven applications where complex query languages like GraphQL introduce new attack surfaces related to query complexity and depth limits.
In terms of industry standards, this vulnerability aligns closely with CWE-787: Out-of-bounds Write or CWE-400: Uncontrolled Resource Consumption, specifically within the context of denial of service attacks. It also maps to MITRE ATT&CK technique T1499: Endpoint Denial of Service, where an adversary aims to disrupt services by exhausting resources. The lack of authentication requirement places it in a high-severity category as per common vulnerability scoring systems, given that remote unauthenticated attackers can trigger the condition without any prior foothold inside the network perimeter.
To mitigate this risk, organizations must prioritize immediate patching. Administrators should upgrade GitLab to version 19.3.2 or later for the 19.3 branch, 19.2.6 or later for the 19.2 branch, and 19.1.8 or later for versions starting from 18.4.6. Until patches are applied, defensive measures can include configuring web application firewalls to rate-limit GraphQL requests or restricting access to the GraphQL endpoint based on IP reputation if feasible within the network architecture. Additionally, monitoring server metrics such as CPU usage and memory consumption during peak hours can help detect anomalous patterns indicative of exploitation attempts. Regular security assessments focusing on API complexity limits are recommended to ensure that future updates do not reintroduce similar weaknesses in resource allocation logic.