GitLab's emergency patch fixes a code-injection bug that let an unauthenticated attacker delete repositories, forge merge records, or ban maintainers in one HTTP request — and researchers reproduced it within minutes of the advisory going live.
GitLab shipped an out-of-band patch on August 17 for CVE-2026-19478, a code-injection bug in its GraphQL API that let anyone on the internet delete a public project, forge its merge history, or ban its maintainers — in one HTTP request, with no account and no login. Researchers at watchTowr reproduced the exploit within minutes of the advisory going live. Attackers were running it for real inside two days.
The flaw carries a 9.4 CVSS score and lives in how a GraphQL directive processes input. GitLab's own advisory calls it code injection, meaning the bug isn't just leaking data — it's letting an outsider get GitLab's server to execute logic it was never supposed to run, on their behalf, with the access level of the platform itself rather than any particular user.
What an attacker could actually do with it
The newly disclosed code injection vulnerability allows an unauthenticated attacker to delete publicly accessible GitLab projects and rewrite their state, deleting repositories entirely, forging merge records, or banning maintainers in a single HTTP request with no credentials, user interaction, or obscure configuration required.
Jake Knott, principal security researcher, watchTowr
That's not a denial-of-service bug and it's not a data leak — it's an outsider getting write access to the thing your team trusts as the source of truth for what shipped. Forging a merge record means the audit trail lies to you. Banning a maintainer mid-incident means the person who'd normally fix this can't log back in to do it.
Affected vs. patched GitLab versions
18.x
Track
18.2 – 18.11.10
Affected (before)
18.11.11
19.0.x
Track
19.0 – 19.0.7
Affected (before)
19.0.8
19.1.x
Track
19.1 – 19.1.5
Affected (before)
19.1.6
19.2.x
Track
19.2 – 19.2.3
Affected (before)
19.2.4
Track
Affected (before)
Patched
18.x
18.2 – 18.11.10
18.11.11
19.0.x
19.0 – 19.0.7
19.0.8
19.1.x
19.1 – 19.1.5
19.1.6
19.2.x
19.2 – 19.2.3
19.2.4
If you're running a self-managed CE or EE instance and haven't upgraded to one of those four builds, do it before anything else on today's list. Help Net Security's reporting confirms GitLab.com and GitLab Dedicated were already running patched code, so this is a self-hosted problem specifically, and a public-instance problem most urgently: the bug only needs your project to be visible, not your login page to be exposed.
GitLab's GraphQL API is the same interface developers and CI pipelines use every day — which is exactly why a flaw in it reaches so far. · Unsplash
There's a second bug riding along, and a bigger risk underneath both
GitLab's same release also fixes CVE-2026-19650, a CSRF flaw (CVSS 7.1) in the GraphQL multiplex query handler that lets an attacker execute mutations through GET requests — a lower bar to exploit in one sense, since it doesn't need code injection, but it does require tricking a logged-in user into visiting a malicious page first. Patch for both; they landed in the same builds.
This is also GitLab's third GraphQL-flavored security release this year, by outside trackers' count — a pattern that says less about any one engineer's mistake and more about GraphQL itself. A REST endpoint typically does one thing; a GraphQL directive can be composed in ways the schema author never tested, and 'a client can ask for almost anything, in almost any shape' is a hard property to fully secure against injection. I don't think GitLab is unusually sloppy here — I think GraphQL keeps making the same class of bug easy to write, at GitLab and elsewhere across the dev-tooling stack.
Self-managed GitLab instances are the ones that needed to act — GitLab.com and GitLab Dedicated were already on patched builds. · Unsplash
Do I need to patch my GitLab instance for CVE-2026-19478?
Yes, if you run self-managed GitLab CE or EE on any version before 18.11.11, 19.0.8, 19.1.6, or 19.2.4. GitLab.com and GitLab Dedicated customers don't need to do anything — those platforms were already running patched code.
Do I need to be logged in to be attacked?
No. CVE-2026-19478 needs no authentication, no user interaction, and no special configuration. Any public GitLab project on an unpatched instance was exposed.
Is CVE-2026-19478 being actively exploited?
Yes. watchTowr's honeypot network detected in-the-wild exploitation attempts roughly two days after GitLab's August 17 patch, and the firm itself reproduced the exploit within minutes of the advisory's release using only the public patch details.
What's CVE-2026-19650, and do I need to worry about it separately?
It's a related but distinct CSRF vulnerability (CVSS 7.1) in GitLab's GraphQL multiplex query handler, fixed in the same builds as CVE-2026-19478. It requires a logged-in victim to visit a malicious page, so it's lower-severity, but there's no reason to patch one and not the other.
What should I check if I think I was already hit?
Look for unexpectedly deleted public projects, merge requests marked as approved by users who didn't actually review them, and maintainers who were removed from a project without anyone on the team doing it.
Supply-chain security spent 2026 mostly talking about poisoned packages — the LiteLLM/Trivy pipeline compromise and npm's Keyv/Cacheable worm both ran through that exact playbook. CVE-2026-19478 is the same risk from the other direction: instead of poisoning a dependency you pull in, an attacker tampers with the platform recording whether your own code was reviewed at all. If you're running self-managed GitLab and you haven't patched yet, that's the actual reason to stop reading and go do it now.
