Update, 21 August 2026: CVE-2026-19478 is now being exploited. watchTowr reports reproducing it within minutes of disclosure and observing in-the-wild exploitation against its honeypot network, and says an attacker can also forge merge records and ban maintainers. If you self-host GitLab, patch now. Our follow-up has the detail.
CVE-2026-19478 is rated CVSS 9.4 and affects both GitLab Community Edition and Enterprise Edition. GitLab's own description is that under certain conditions an unauthenticated user could remotely modify or delete public projects and user data through a GraphQL directive.
Patches shipped on 17 August 2026, outside the normal release schedule. GitLab.com and GitLab Dedicated were already covered.
Fixed in
| Affected | Upgrade to |
|---|---|
| 18.2 – 18.11.10 | 18.11.11 |
| 19.0 before 19.0.8 | 19.0.8 |
| 19.1 before 19.1.6 | 19.1.6 |
| 19.2 before 19.2.4 | 19.2.4 |
An unscheduled release at CVSS 9.4 is GitLab telling you the severity in the only language that is hard to misread. The regular patch train exists precisely so this does not have to happen.
Why deletion is a different problem
Most critical bugs are about someone reading what they should not, or running code they should not. This one is about destruction, and destruction has a property the others do not: there is no window in which to detect it and prevent the harm. By the time it is in your logs it has already happened.
For a self-hosted GitLab that means the recovery question is not "what did they see" but "do we have a restore". Repository history usually survives in developers' clones. Everything wrapped around it — issues, merge requests, review history, CI configuration, wiki, releases — lives only in the instance.
The second flaw patched alongside is CVE-2026-19650, CVSS 7.1: a cross-site request forgery weakness in GraphQL multiplex query handling that GitLab says could have allowed an unauthenticated user to execute mutations through GET requests, due to improper request validation. It needs user interaction, so it is the lesser of the two — but a state-changing mutation reachable by GET is exactly the thing a link in a chat message can trigger.
GraphQL keeps producing these
Not because GraphQL is insecure, but because of where the authorisation lives.
A REST API tends to check permissions per endpoint, and an endpoint is a thing you can enumerate and test. A GraphQL API takes one arbitrary query describing what the caller wants, and the checks have to hold across every path through the schema — including directives, aliases, and multiplexed batches of queries in one request. Both flaws here are in that seam: one in directive handling, one in multiplex handling. Neither is in the resolvers people actually review.
From patch to exploitation in days
As of 18 August 2026 GitLab reported no known exploitation and no public exploit code. That held for a matter of days: by 21 August watchTowr had reproduced the flaw within minutes of disclosure and was seeing it used against its honeypots.
The reasoning below was written before that happened, and it turned out to understate the speed. GitLab publishes technical detail roughly 90 days after the patch, which puts disclosure around mid-November 2026 — and in practice, a well-resourced attacker diffs the patch commits within days, not months. Self-hosted GitLab is also a high-value target by definition: it holds source, deploy keys and CI credentials, which is why the CI secrets problem and the Mozilla signing key left in a private repo both started somewhere like it.
What to do
- Patch now if you self-host. GitLab.com and Dedicated are done; nothing else is.
- Check whether your instance is reachable without authentication. The precondition involves public projects and unauthenticated access, so an instance that is not exposed is in a very different position from one that is.
- Verify your backups actually restore. Not that they exist — that a restore has been performed. A destructive bug is the case where an untested backup is discovered to be no backup.
- Review who can make projects public. Public visibility on a self-hosted instance is often a default nobody revisited.
- Do not wait for the disclosure date. The 90-day clock protects unpatched users from a published write-up. It does not protect them from anyone reading the diff.
What is not established
- The exact conditions required. GitLab says "under certain conditions" and has not elaborated, which is deliberate while instances are unpatched.
- How widely it is being exploited. Confirmed in the wild from 21 August; no victim count has been published.
- How many self-hosted instances are exposed. No count has been published.
