GitLab released 19.2.4, 19.1.6, 19.0.8, and 18.11.11 on August 17, 2026, outside its usual twice-monthly patch schedule. The full advisory, with severities and CVE IDs, is on GitLab's critical patch release page. Two GraphQL bugs are fixed; one of them is bad enough that GitLab pushed the release off-cycle and self-managed teams are already being hit.
The 60-second version
- CVE-2026-19478 is critical (CVSS 9.4): an unauthenticated attacker can modify or delete public projects and user data via a GraphQL directive.
- A second fix, CVE-2026-19650 (high, CVSS 7.1), is a CSRF issue in GraphQL multiplex query handling.
- Fixed in 19.2.4, 19.1.6, 19.0.8, and 18.11.11. Everything from 18.2 up is affected.
- GitLab.com and Dedicated are already patched. Self-managed installs are the ones that need to act.
- It is being exploited in the wild already. Patch, don't wait for a maintenance window.
What CVE-2026-19478 actually is
In GitLab's own words, the issue "could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive." No login, no user interaction, low attack complexity. That combination is why it carries a CVSS score of 9.4 and a critical rating. It was reported through GitLab's HackerOne bug bounty program by a researcher credited as hiimguardian.
The same release fixes CVE-2026-19650, rated high (CVSS 7.1), which GitLab describes as a flaw that "could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling." Both live in the GraphQL API, which is the same surface a lot of external tooling, dashboards, and integrations read from.
Affected ranges, per the advisory: every version 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. If your instance predates the patch level for its line, assume it is vulnerable.
It is already being exploited
This is not a theoretical patch-when-convenient advisory. Security firm watchTowr reported observing in-the-wild exploitation against its honeypot network within days of disclosure, and said it reproduced the vulnerability within minutes of the advisory going out. Jake Knott, a principal security researcher there, framed the speed bluntly: "This is the new reality of vulnerability reproduction and exploitation, where AI-enabled attackers are able to compress the time from disclosure to exploitation."
The practical read: the gap between "advisory published" and "someone is scanning your instance" is now measured in hours. Treat this as an emergency change and skip the usual backlog queue.
What to do
Upgrade to the patched release for the line you are on. GitLab shipped a fix for each supported line on purpose, so you can take the security fix without also taking a minor-version jump:
- On 19.2.x, go to 19.2.4.
- On 19.1.x, go to 19.1.6.
- On 19.0.x, go to 19.0.8.
- On 18.x, go to 18.11.11.
GitLab "strongly recommend[s] that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible." If you are on GitLab.com or GitLab Dedicated, GitLab has already applied the fix and there is nothing for you to do. If you jump a minor line while you are in there (say 19.0.x straight to a 19.1 or 19.2 release), read that release's breaking changes first so a security patch doesn't turn into a surprise upgrade. The 19.0 upgrade gotchas cover the webhook-signing and CI-token changes that catch people on the way up.
Full disclosure: we make PRFlow, a GitLab-to-Slack tool that reads GitLab's API to post one updating message per merge request. Vulnerabilities in that API surface are a fair reminder to audit what your integrations can reach: PRFlow asks for read access scoped to the projects it notifies on, nothing wider, and the GitLab integration page spells out exactly what it needs and why. After you patch, spend ten minutes confirming the tokens your other tools hold are scoped just as tightly.
Why GitLab's API surface keeps showing up in advisories
This is the second GitLab security release in a month that lands in the APIs review tooling talks to. The August 12 patch tightened authorization on the merge requests, external status check, and pipeline APIs; this one closes an unauthenticated hole in GraphQL. Merge-request review moved into chat and dashboards years ago, so those endpoints are load-bearing for daily work, and GitLab has been hardening them release over release. The upside of that cadence is a steady stream of fixes; the cost is that you have to actually apply them.
Bottom line
Patch to 19.2.4, 19.1.6, 19.0.8, or 18.11.11 now, ahead of the next sprint boundary. CVE-2026-19478 is unauthenticated, critical, and already being exploited, and the only mitigation GitLab lists is the upgrade. Once you are patched, a quick pass over your integration tokens keeps the next GraphQL bug from being your problem.