Introduction
A five year old flaw in GitLab's GraphQL API quietly gave any unauthenticated user the ability to bring a self managed GitLab instance to its knees with nothing more than repeated HTTP requests. CVE-2025-12664, patched on April 8, 2026, addresses an improper input quantity validation issue that allowed volumetric denial of service against GitLab CE and EE installations spanning every release from 13.0 onward.
Given GitLab's position as a Leader in the 2024 Gartner Magic Quadrant for DevOps Platforms and its nearly $1 billion in annual revenue, the blast radius of this vulnerability is substantial. Any internet facing, self managed GitLab instance running an unpatched version is a viable target, and the attack requires zero authentication.
Technical Information
Root Cause: CWE 1284 and Missing Volumetric Controls
The vulnerability is classified under CWE 1284: Improper Validation of Specified Quantity in Input. At its core, the GitLab GraphQL API did not adequately validate or constrain the volume and frequency of incoming GraphQL queries from unauthenticated users. This is a distinct issue from query complexity validation. GitLab already implements complexity scores for individual GraphQL queries and enforces a 30 second timeout per request. However, those controls address the computational cost of a single query, not the sheer number of queries an unauthenticated client can submit in rapid succession.
The absence of strict volumetric rate limiting on the general GraphQL endpoint meant the server would continuously accept and process incoming queries regardless of how many were being submitted. An attacker could simply flood the endpoint with repeated GraphQL queries, and the backend would dutifully attempt to service each one.
Attack Flow
The exploitation path is straightforward:
- An attacker identifies a publicly accessible GitLab instance (CE or EE) running any version from 13.0 through the unpatched 18.10.x, 18.9.x, or 18.8.x branches.
- The attacker sends a high volume of GraphQL queries to the
/api/graphqlendpoint. No authentication token or session cookie is required. - The GitLab backend begins processing each query. Because there is no volumetric cap on unauthenticated requests, the server allocates resources (CPU, memory, Sidekiq workers) for every incoming query.
- The Sidekiq job queues fill up as the system struggles to keep pace with the incoming request volume.
- Legitimate queries from authenticated users begin experiencing severe latency, eventually hitting the 30 second timeout threshold and failing.
- In extreme cases, the resource exhaustion triggers Out of Memory (OOM) kills at the operating system level, effectively taking the GitLab instance offline.
The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H accurately reflects this attack profile: network accessible, low complexity, no privileges required, no user interaction needed, and high impact to availability with no impact to confidentiality or integrity.
Distinction from Related GraphQL Vulnerabilities
It is worth noting that this vulnerability is mechanistically different from the earlier related issues CVE-2025-8014 and CVE-2025-10004, which targeted CWE 770 (resource allocation without limits or throttling) and involved bypassing query complexity limits. CVE-2025-12664 is specifically about validating the specified quantity of input operations rather than the computational cost of each individual query. The fix therefore introduces a different class of control.
Patch Information
GitLab addressed CVE-2025-12664 in a coordinated patch release published on April 8, 2026. The fix was shipped across three supported branches simultaneously, covering both GitLab Community Edition and Enterprise Edition. GitLab.com was already running the patched version at the time of disclosure, and GitLab Dedicated customers required no additional action.
The patched versions are:
| Branch | Fixed Version |
|---|---|
| 18.8.x | 18.8.9 |
| 18.9.x | 18.9.5 |
| 18.10.x | 18.10.3 |
Note that GitLab skipped version numbers 18.10.2, 18.9.4, and 18.8.8; there are no packages with those versions.
The fix centers on introducing proper input quantity validation on the GraphQL endpoint. While the exact code diff is not yet publicly available (the associated GitLab work item gitlab-org/gitlab#579376 remains confidential, as is standard GitLab practice for the 30 days following a security release), the nature of the CWE and advisory description tell us what was remediated. GitLab added controls to validate and constrain the quantity of GraphQL queries an unauthenticated user can issue, effectively capping the resource consumption that repeated queries could cause.
The patch release does not include any new database migrations, and multi node deployments should not require downtime to apply it. Administrators using Omnibus packages should be aware that the system will automatically stop, run migrations, and restart by default. To prevent this behavior during updates, administrators can add a skip auto reconfigure file to their configuration.
Defense in Depth: Rate Limiting Configuration
Beyond patching, administrators should review their instance level rate limits as an additional layer of protection. GitLab allows administrators to configure User and IP rate limits, which are disabled by default:
| Rate Limit Type | Default Status | Recommended Action |
|---|---|---|
| User and IP Rate Limits | Disabled | Enable in Admin area to throttle unauthenticated IPs |
| Raw Endpoint Limits | 800 requests per minute | Monitor for abuse |
| GraphQL aiAction Mutation | 160 calls per 8 hours | Leave as default (not configurable) |
Enabling User and IP rate limits provides a meaningful layer of defense against volumetric attacks targeting the API, even after patching.
Affected Systems and Versions
The vulnerability affects an exceptionally broad range of GitLab releases:
- GitLab CE and EE 18.10.x: versions 18.10.0 through 18.10.2 (fixed in 18.10.3)
- GitLab CE and EE 18.9.x: versions 18.9.0 through 18.9.4 (fixed in 18.9.5)
- GitLab CE and EE 18.8.x and all older branches: all versions from 13.0 through 18.8.8 (fixed in 18.8.9)
This means the vulnerability has been present in the GitLab codebase for over five years, spanning hundreds of individual releases. Any self managed GitLab instance running a version within these ranges and exposing the GraphQL API to untrusted networks is vulnerable.
GitLab SaaS (gitlab.com) and GitLab Dedicated instances are not affected, as GitLab applied the patch to its hosted infrastructure prior to public disclosure.
Vendor Security History
GitLab maintains a transparent and well resourced security program. The company operates one of the most active bug bounty programs on HackerOne, having paid out over $6.4 million in total bounties to date. CVE-2025-12664 was itself discovered through this program by the researcher foxribeye (HackerOne Report #3377091).
GitLab follows a strict patch cadence, releasing scheduled security updates twice a month. The company publishes technical details of vulnerabilities on their issue tracker 30 days after a patch is released, giving administrators a defined window to apply fixes before exploitation details become public. This 30 day disclosure window is particularly relevant here: organizations should treat it as a hard deadline for patching, as threat actors routinely monitor GitLab's issue tracker for newly unsealed vulnerability details.
The related GraphQL denial of service issues CVE-2025-8014 and CVE-2025-10004 (targeting CWE 770) indicate that the GraphQL API has been a recurring area of security concern, with multiple researchers identifying different classes of resource exhaustion vulnerabilities in the same subsystem.
References
- GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9
- CVE-2025-12664 on CVE.org
- CVE-2025-12664 on NVD
- GitLab Work Item #579376 (confidential)
- HackerOne Report #3377091
- CWE 1284: Improper Validation of Specified Quantity in Input
- GitLab Rate Limits Documentation
- GitLab Application Limits Documentation
- GitLab Community Forum: High GraphQL Latency Since GitLab 18+
- GitLab Bug Bounty Program on HackerOne
