Patches unauthenticated GraphQL DoS in GitLab CE/EE
TL;DR — GitLab fixed a High-severity unauthenticated DoS where repeated GraphQL queries can make GitLab instances unresponsive; self-managed teams should prioritize upgrading to patched patch releases.
What happened
GitLab is a DevSecOps platform used for source control, CI/CD, and security scanning in a single application. In its April 8, 2026 patch release, GitLab disclosed and remediated CVE-2025-12664: an issue where an unauthenticated user can cause denial of service by sending repeated GraphQL queries.
| Item | Source value |
|---|---|
| Affected software | GitLab Community Edition (CE) / Enterprise Edition (EE) |
| Impact (per source) | Unauthenticated denial of service by sending repeated GraphQL queries |
| Severity | CVSS 7.5 (High), CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| Impacted versions | GitLab CE/EE: all versions from 13.0 before 18.8.9, 18.9 before 18.9.5, and 18.10 before 18.10.3 |
| Patched versions | 18.8.9, 18.9.5, 18.10.3 |
GraphQL endpoints are commonly internet-reachable in self-managed GitLab deployments (directly or via an ingress/proxy). Availability bugs in API query execution are a recurring incident class for platform teams because they’re easy to trigger at scale and hard to distinguish from “legitimate” traffic spikes.
Who is impacted
- Self-managed GitLab CE/EE installations in the impacted version ranges (
13.0+ prior to the patched patch releases listed above). - Any deployment where the GitLab GraphQL API is reachable by untrusted clients (e.g., internet-exposed, partner-accessible, or broadly accessible internal networks), since the issue is described as unauthenticated.
What to do now
- Follow vendor remediation guidance and upgrade to a patched release.
"These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately."
- Prioritize patching externally reachable GitLab instances first (or those reachable by large internal populations), since the weakness is exploitable without authentication.
- Treat this primarily as an availability risk: review edge controls (WAF/API gateway rules, rate limits, request body limits) around GitLab endpoints that service GraphQL requests to reduce blast radius during rollout.
- Validate hosting context:
"GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action."
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.