GitLab Patches Critical Unauthenticated GraphQL Vulnerability
GitLab issued an emergency patch for a critical unauthenticated GraphQL flaw (CVE-2026-19478, CVSS 9.4) enabling remote modification or deletion of public projects.
GitLab patched CVE-2026-19478 (CVSS 9.4), an unauthenticated GraphQL directive flaw allowing remote modification or deletion of public projects and user data on self-managed servers. The emergency patch released August 17 covers versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11, but no fixes exist for the 18.2-18.10 branches. A second issue, a CSRF weakness in GraphQL multiplex queries (CVE-2026-19650, CVSS 7.1), shipped in the same release. No exploitation or public PoC has been observed; the flaw was reported by hiimguardian through HackerOne.
- CVE-2026-19478 (CVSS 9.4) requires no credentials or user interaction to modify or delete public projects
- Patches available for 19.2.4, 19.1.6, 19.0.8, and 18.11.11; branches 18.2-18.10 receive no fix
- CVE-2026-19650 (CVSS 7.1) is a CSRF flaw letting unauthenticated users trigger GraphQL mutations via GET requests
- Reported through HackerOne by hiimguardian; no evidence of in-the-wild exploitation or public PoC
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-19478 +1 in the same advisory: …19650 | Unauthenticated GraphQL Code Injection in GitLab CE/EE Enables Data Tampering GitLab has patched a critical (CVSS 9.1) code injection flaw (CWE-94) in how GitLab Community Edition (CE) and Enterprise Edition (EE) process GraphQL directives. Under certain conditions, an unauthenticated remote attacker can abuse a GraphQL directive to modify or delete public projects and user data on affected instances, requiring no privileges or user interaction; the impact is to integrity and availability, not confidentiality. Affected versions span all GitLab CE/EE releases from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4, which covers self-managed installations as well as the same codebase that powers the GitLab.com SaaS. News reports indicate the flaw came under active exploitation within days of disclosure, and EPSS assigns a 5.8% probability of exploitation within 30 days (93rd percentile). It is not yet listed in CISA's KEV catalog and no public proof-of-concept is known, but defenders should treat it as an actively exploited, unauthenticated, high-impact issue. Do: Upgrade all GitLab CE/EE instances to 18.11.11, 19.0.8, 19.1.6, or 19.2.4 (or later) immediately, prioritizing internet-facing instances given confirmed active exploitation. Until patched, restrict unauthenticated access to the GraphQL API endpoint at the network or WAF layer. Review instance audit logs and public projects for signs of unauthorized modifications or deletions of projects and user data. | 9.1 group max | 6% |
| massmillions of users (GitLab.com SaaS runs the same code) plus tens of thousands of internet-exposed self-managed CE/EE instances |
Full article417 words · extracted from securityaffairs.com · click to collapse
GitLab patched a critical GraphQL flaw that let unauthenticated attackers remotely modify or delete public projects on self-managed servers.
GitLab pushed out an emergency patch this week to address a critical flaw, tracked as CVE-2026-19478 (CVSS score of 9.4), that could let an attacker with zero credentials remotely modify or delete public projects and user data.
“GitLab has remediated an issue that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive.” reads the advisory.
GitLab issued an emergency patch on August 17, five days after its regular update. The vulnerability impacts only self-managed installations, users should upgrade to versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11.
There’s a gap worth flagging for anyone still sitting on an older release. The available patches don’t cover the 18.2 through 18.10 branches, even though those versions technically fall inside the affected range. If you’re running anything in that window, staying put isn’t really an option; you’ll need to upgrade to a patched branch entirely rather than waiting for a fix that isn’t coming for your current one.
hiimguardian reported the flaw through the company HackerOne bug bounty program.
A second, less severe issue shipped in the same release. CVE-2026-19650 (CVSS score of 7.1), involves a cross-site request forgery weakness in how GitLab’s GraphQL handles multiplex queries, letting an unauthenticated attacker trigger mutations through GET requests due to improper validation. Unlike the critical flaw, this one needs a victim to actually interact with something, so it’s a real risk but a considerably narrower one.
There’s no evidence either bug has been exploited in the wild yet, and no public proof-of-concept code has surfaced as of publication. That’s the good news. The less comforting part is GitLab’s own disclosure policy: full technical details typically go public on the company’s issue tracker 90 days after the patching release, which puts a working understanding of exactly how this bug functions squarely in mid-November, plenty of time for someone motivated enough to reverse-engineer the patch diff themselves before then.
This is not the first serious GitLab issue in recent months. Last month, researchers released working exploit code for another remote-code-execution flaw affecting self-managed servers. Organizations running GitLab on their own infrastructure should therefore treat this patch as a priority, especially given the critical severity and the fact that the vulnerability requires no authentication or user interaction.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, GitLab)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/197454/hacking/gitlab-patches-critical-unauthenticated-graphql-vulnerability.html