Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid API credentials
-
DeliveryCraft GraphQL query with resource-intensive pattern
-
ExploitSubmit query repeatedly to API endpoint
-
ExecutionExhaust server resources (CPU, memory)
-
ImpactDegrade or crash GitLab service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Valid GitLab API authentication (session token, personal access token, or OAuth token) is required to access the GraphQL API endpoint. The vulnerability triggers when an authenticated user submits GraphQL queries without the API enforcing resource allocation limits-this is the default configuration in affected versions. No special GitLab feature flags, non-standard configuration, or privileged account role are required; any authenticated user (including read-only accounts) can exploit the vulnerability. Exploitation is NOT limited by user role, project membership, or admin privileges. The attack does not require user interaction beyond submitting the malicious query. The scope is unchanged (SU), meaning the attacker's own resources are consumed, but denial of service affects the shared GitLab instance and all its users. |
| Impact | CVSS 6.5 with AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates a network-accessible vulnerability with low attack complexity and high availability impact, but requiring authenticated access (PR:L). SSVC framework assessment rates Exploitation as 'poc' (publicly available code exists but not automated weaponization), Automatable as 'no' (human interaction required to craft effective payloads), and Technical Impact as 'partial' (denial of service only; no data exfiltration or integrity compromise). The requirement for valid authentication significantly reduces real-world attack surface compared to unauthenticated DoS vectors, as attackers must either compromise legitimate credentials or exploit accounts with API access. However, the low attack complexity and public exploit code mean that once an attacker gains authentication (e.g., via phished credentials, insider threat, or compromised API token), exploitation is straightforward and requires no special skill. Priority depends on credential hygiene: organizations with strong API key rotation, single-use tokens, and audit logging can detect abuse quickly; those with long-lived shared tokens or weak monitoring face greater risk. The partial technical impact (DoS only) suggests this is a legitimate but not critical priority compared to RCE or data exfiltration vulnerabilities. |
| Exploit ScenarioDerived | An attacker with valid GitLab API credentials (obtained via credential compromise or social engineering) constructs a malicious GraphQL query with excessive nesting or expensive aggregations-for example, a query requesting deeply nested user, project, and issue relationships with no depth limit. The attacker submits the query via the GitLab GraphQL endpoint multiple times in rapid succession, forcing the server to allocate memory and CPU cycles without hitting resource limits. Within seconds to minutes, the GitLab instance consumes available memory or CPU, becoming unresponsive to legitimate users and API requests. Publicly available exploit code (documented in the HackerOne report) provides ready-made payloads, lowering the barrier to entry. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 23, 2026
Authenticated users can trigger denial of service in GitLab by overwhelming system resources through the GraphQL API due to insufficient resource allocation limits. Affected versions span from 12.4 through 18.11.0 across three release branches. Publicly available exploit code exists, though active exploitation has not been confirmed in CISA KEV. CVSS 6.5 reflects moderate severity with high availability impact but requires valid authentication.
RemediationAI
Apply the vendor-released patches immediately: upgrade to GitLab 18.9.6 or later for legacy instances, 18.10.4 or later for the 18.10 branch, and 18.11.1 or later for the 18.11 branch. See the official patch release announcement at https://about.gitlab.com/releases/2026/04/22/patch-release-gitlab-18-11-1-released/. As an interim compensating control, implement API rate limiting at the proxy or load balancer level (e.g., WAF rules limiting GraphQL queries per authenticated user per minute) to throttle expensive queries, though this does not address the root cause. Additionally, monitor GraphQL API logs for unusual query patterns (deeply nested selections, high execution time, resource consumption spikes) and alert on per-user query rates exceeding baseline. Restrict API token scope and implement short-lived token expiration (e.g., 24-hour max lifetime) to limit the window of compromise. Note that these controls may impact legitimate heavy API consumers; test thoroughly in staging before production deployment.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability resides in the GraphQL API layer of GitLab, which handles structured query processing for authenticated API consumers. CWE-770 (Allocation of Resources Without Limits or Throttling) indicates that the API endpoint fails to enforce per-user or per-session resource quotas on query execution, computation time, or memory allocation. An authenticated attacker can craft deeply nested or computationally expensive GraphQL queries that consume CPU, memory, or other finite system resources without triggering protective rate limits or timeouts. The affected product spans all GitLab Community Edition and Enterprise Edition instances from version 12.4 onward, with the vulnerability present across multiple actively-maintained release branches (18.9, 18.10, 18.11).
Know when Gitlab gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Primary rating from Vendor (GitLab) · only source for this CVE.
CVSS VectorVendor: GitLab
Lifecycle Timeline
4DescriptionCVE.org
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.4 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that could have allowed an authenticated user to cause denial of service by overwhelming system resources under certain conditions due to insufficient resource allocation limits in the GraphQL API.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.9. Rated critical severity (CVSS 10
An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.
When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab af
Unauthenticated arbitrary file read in GitLab CE/EE lets remote attackers retrieve files from the GitLab server via the
The SSH key upload feature (lib/gitlab_keys.rb) in gitlab-shell before 1.7.3, as used in GitLab 5.0 before 5.4.1 and 6.x
A vulnerability in GitLab CE/EE affecting all versions from 11.10 prior to 15.1.6, 15.2 to 15.2.4, 15.3 to 15.3.2 allows
Remote code execution in GitLab CE/EE (all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2)
Remote code execution in GitLab CE/EE can be triggered by a specially crafted regular expression processed through a vul
Sensitive credential and configuration disclosure in GitLab Enterprise Edition allows an authenticated user with Duo Cha
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Authenticated code execution on the GitLab server is possible in GitLab CE/EE 19.2 through 19.4.0, where an integer over
EUVD-2025-209551
GHSA-q9qr-p283-j9rm
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB