Brief Summary: GitLab GraphQL API Denial of Service via Repeated Unauthenticated Queries (CVE-2025-12664)

Introduction

A five-year-old flaw in GitLab's GraphQL API let any unauthenticated user bring a self-managed GitLab instance to its knees with nothing more than repeated HTTP requests. CVE-2025-12664, patched on April 8, 2026, is an improper input quantity validation issue that allowed volumetric denial of service against GitLab CE and EE installations in every release from 13.0 onward.

GitLab is a Leader in the 2024 Gartner Magic Quadrant for DevOps Platforms and brings in nearly $1 billion in annual revenue, so 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. The GitLab GraphQL API did not adequately validate or constrain the volume and frequency of incoming GraphQL queries from unauthenticated users. That is a separate problem from query complexity validation. GitLab already assigns complexity scores to individual GraphQL queries and enforces a 30-second timeout per request, but those controls address the computational cost of a single query. They do not address the sheer number of queries an unauthenticated client can submit in rapid succession.

Without strict volumetric rate limiting on the general GraphQL endpoint, the server kept accepting and processing incoming queries no matter how many arrived. An attacker could flood the endpoint with repeated GraphQL queries, and the backend would dutifully try to service each one.

Attack Flow

The exploitation path is straightforward:

1. 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.
2. The attacker sends a high volume of GraphQL queries to the /api/graphql endpoint. No authentication token or session cookie is required.
3. The GitLab backend starts processing each query. Because there is no volumetric cap on unauthenticated requests, the server allocates resources (CPU, memory, Sidekiq workers) for every incoming query.
4. The Sidekiq job queues fill up as the system struggles to keep pace with the incoming requests.
5. Legitimate queries from authenticated users slow down badly, eventually hit the 30-second timeout, and fail.
6. In extreme cases, the resource exhaustion triggers out-of-memory (OOM) kills at the operating system level and takes 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 reflects this attack profile accurately: network accessible, low complexity, no privileges required, no user interaction needed, high impact to availability, and no impact to confidentiality or integrity.

Distinction from Related GraphQL Vulnerabilities

This vulnerability works differently from the earlier related issues CVE-2025-8014 and CVE-2025-10004, which fell under CWE 770 (resource allocation without limits or throttling) and involved bypassing query complexity limits. CVE-2025-12664 is about validating the specified quantity of input operations, not the computational cost of each individual query, so the fix introduces a different class of control.

Patch Information

GitLab fixed CVE-2025-12664 in a coordinated patch release published on April 8, 2026. The fix shipped on three supported branches at once, for both GitLab Community Edition and Enterprise Edition. GitLab.com was already running the patched version at the time of disclosure, and GitLab Dedicated customers needed no additional action.

The patched versions are:

GitLab skipped version numbers 18.10.2, 18.9.4, and 18.8.8. There are no packages with those versions.

The fix adds proper input quantity validation to the GraphQL endpoint. The exact code diff is not yet public (the associated GitLab work item gitlab-org/gitlab#579376 remains confidential, as is standard GitLab practice for the 30 days after a security release), but the CWE and the advisory description tell us what was remediated. GitLab added controls that validate and constrain the quantity of GraphQL queries an unauthenticated user can issue, which caps the resource consumption that repeated queries could cause.

The patch release includes no new database migrations, and multi-node deployments should not need downtime to apply it. On Omnibus packages, the system automatically stops, runs migrations, and restarts by default. Administrators who want to prevent this during updates 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 lets administrators configure User and IP rate limits, which are disabled by default:

Enabling User and IP rate limits adds a meaningful defense against volumetric attacks on 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)

The vulnerability has been in the GitLab codebase for over five years, across hundreds of individual releases. Any self-managed GitLab instance running a version in these ranges and exposing the GraphQL API to untrusted networks is vulnerable.

GitLab SaaS (gitlab.com) and GitLab Dedicated instances are not affected, because GitLab applied the patch to its hosted infrastructure before public disclosure.

Vendor Security History

GitLab runs a transparent, well-resourced security program. Its bug bounty program is one of the most active on HackerOne and has paid out over $6.4 million in total bounties to date. The researcher foxribeye found CVE-2025-12664 through this program (HackerOne Report #3377091).

GitLab follows a strict patch cadence, with scheduled security updates twice a month. It publishes technical details of vulnerabilities on its issue tracker 30 days after a patch is released, which gives administrators a defined window to apply fixes before exploitation details become public. Organizations should treat that 30-day window as a hard deadline for patching, because 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 (CWE 770) indicate that the GraphQL API has been a recurring area of security concern, with multiple researchers finding 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