GitLab shipped an out-of-cycle critical security release on August 17, 2026, patching a GraphQL flaw tracked as CVE-2026-19478 (CVSS 9.4). The bug let an unauthenticated attacker send a crafted GraphQL directive to remotely delete or modify public projects and user data on self-managed GitLab Community Edition and Enterprise Edition instances. GitLab.com and GitLab Dedicated were already running the fix before the advisory went public, so only self-managed installs need action.
What the GitLab GraphQL vulnerability actually does
CVE-2026-19478 is a code injection issue (CWE-94) in how GitLab’s GraphQL API processes directives. No authentication, no user interaction, and low attack complexity are required, which is what pushes the CVSS score to 9.4. A successful request can delete or alter a public project and the user data tied to it, meaning repositories, issues, and related records are on the table, not just a denial of service.
The same release also fixes CVE-2026-19650, a high-severity cross-site request forgery flaw (CVSS 7.1) in GitLab’s GraphQL multiplex query handler. It lets an unauthenticated attacker trigger GraphQL mutations through ordinary GET requests, sidestepping the request validation that’s supposed to block that. Both issues came in through GitLab’s HackerOne bug bounty program, reported by researchers going by hiimguardian and kreep.
Affected versions and what to patch to
Both flaws affect GitLab CE and EE across four release lines:
- 18.2 through 18.11.10, fixed in 18.11.11
- 19.0 through 19.0.7, fixed in 19.0.8
- 19.1 through 19.1.5, fixed in 19.1.6
- 19.2 through 19.2.3, fixed in 19.2.4
GitLab says the patch set doesn’t include any new database migrations, so a zero-downtime deploy is realistic for most setups. If your team runs a self-managed GitLab instance, this isn’t one to leave in the update backlog. An unauthenticated, network-reachable flaw that can wipe out public projects is exactly the kind of bug that gets scanned for within days of the advisory going public.
Who should actually care
This one matters most for teams and agencies running their own GitLab server rather than using GitLab.com, especially anyone hosting client repositories or CI/CD pipelines on it. If nobody owns patch cadence for internal dev tooling, self-managed instances are exactly where security advisories like this one sit unread for weeks. It’s the kind of gap that turns up during a Web Application Development engagement, right alongside the deployment pipeline and infrastructure review that comes with taking over a codebase.
Update: August 22, 2026
watchTowr, an attack surface management firm, reported that CVE-2026-19478 is now being actively exploited in the wild. According to watchTowr researcher Jake Knott, the firm’s honeypot network picked up the first in-the-wild exploitation attempts on August 20, 2026, just three days after GitLab shipped the patch. Attackers are using the flaw to delete public repositories, forge merge records so a fix looks like it landed when it didn’t, and ban project maintainers from their own repos.
If a self-managed instance still isn’t patched, this is not one to leave for the next maintenance window. watchTowr’s guidance for teams that can’t patch immediately: restrict unauthenticated access to /api/graphql, or pull public repository access entirely. To check whether an instance has already been hit, search web server logs for requests containing @gl_introduced.
Sources
- GitLab: Critical Patch Release 19.2.4, 19.1.6, 19.0.8, 18.11.11
- NVD: CVE-2026-19478
- The Hacker News: Critical GitLab GraphQL Flaw Could Let Unauthenticated Attackers Delete Public Projects
- The Hacker News: GitLab CVE-2026-19478 Comes Under Active Exploitation Within Days of Disclosure
- SecurityWeek: Critical GitLab Flaw Exploited Shortly After Disclosure
