GitLab shipped an emergency patch for a flaw that let anyone delete public projects
CVE-2026-19478 scored 9.4 and needed no login at all. GitLab.com was never at risk — self-managed installs are the ones that have to move.
By Himanshu Bhatt· 3 min read· August 24, 2026
- CVE-2026-19478 scored 9.4 — code injection through a GraphQL directive in GitLab CE and EE.
- No login and no user interaction were required; an attacker could modify or delete public projects and user data.
- Fixed in 19.2.4, 19.1.6, 19.0.8 and 18.11.11, released out of band on 17 August 2026.
- GitLab.com and GitLab Dedicated were already patched — only self-managed installs need to act.
- No exploitation and no public exploit code were known at the time of the fix.
On this page(show)(close)
GitLab pushed an emergency patch on 17 August 2026 for a flaw that required no account, no credentials and no interaction from anyone: CVE-2026-19478, a code injection through a GraphQL directive, rated CVSS 9.4. In GitLab's own words, it "could allow an unauthenticated user to remotely modify or delete public projects and user data." GitLab.com and GitLab Dedicated were already running the fix. Self-managed installations are the ones that have to move.
What made this one a 9.4
Severity scores get quoted a lot and understood rarely, so it is worth spelling out what pushes this one so high. Three things stack: it is exploitable remotely, it needs no authentication, and it requires no user interaction — nobody has to click anything or be logged in for it to work. Add an impact that includes deleting projects and user data, and there is very little left to subtract. The attack surface is a GraphQL directive, part of the API layer GitLab exposes for querying its own data.
The timing says something
GitLab ships patches on a schedule — twice monthly, on the second and fourth Wednesdays. This one did not wait for it. It landed five days after a routine patch release that contained nothing rated critical, which is the clearest signal available about how the issue was regarded internally. Vendors do not break their own release cadence for problems they think can wait a fortnight.
Nobody had used it yet
Worth stating plainly, because "critical" and "under attack" get conflated: as of 18 August 2026 there was no known exploitation and no public exploit code. That is the good version of this story — the flaw was found and fixed before it was weaponised. It is also why the window matters. Once a patch is public, the diff is public, and working out what changed is a well-practised craft. The safest moment to upgrade is now, not after somebody publishes a proof of concept.
Frequently asked questions
- Am I affected?
- If you self-host GitLab CE or EE on 18.2 or later and have not upgraded to 19.2.4, 19.1.6, 19.0.8 or 18.11.11, yes. GitLab.com and Dedicated are already patched.
- Does an attacker need an account?
- No. That is what makes it a 9.4 — no credentials, no user interaction, exploitable remotely.
- What could they do?
- Modify or delete public projects and user data, in GitLab's own description.
- Has anyone actually exploited it?
- Not as far as either source reports. No known exploitation and no public exploit code as of 18 August 2026.
- Is my private code at risk?
- GitLab's wording specifies public projects and user data. Upgrade regardless — the fix is the same either way.
- Why was this released off-schedule?
- GitLab patches on the second and fourth Wednesdays. This came five days after a routine release with no critical issues, which suggests it was not considered safe to hold.
Where to go next
Produced with AI assistance. Every figure was read from The Hacker News' and Help Net Security's reporting on 19 August 2026, including GitLab's own quoted statement. Reviewed by a human editor before publish.
Related Stories & Next Reads
Don't miss the next deep-dive
Weekly breakdowns of the tools students and builders actually use.
No spam·Unsubscribe any time·Privacy-first