GitLab’s Critical GraphQL Flaw Went From Patch to Live Exploitation in Two Days

GitLab pushed an emergency patch on 17 August for a critical GitLab GraphQL vulnerability. The bug let anyone delete public repositories over the open internet, no login needed. Two days later, researchers at watchTowr watched real attackers try it against their own honeypots. For any business running GitLab on its own servers, that’s the pattern to plan around now. The gap between a patch landing and criminals using the bug it fixes has shrunk to almost nothing.

What the GitLab GraphQL vulnerability actually does

The bug is tracked as CVE-2026-19478. It carries a CVSS score of 9.4 out of 10, close to the maximum. GitLab’s own advisory describes it plainly. Under certain conditions, an unauthenticated user could remotely modify or delete public projects and user data through a GraphQL directive. GraphQL is the query language behind GitLab’s web interface and its API. This particular directive wasn’t checking who was asking before it acted.

No password was needed. No session token, and no click from a victim either. An attacker only had to know the address of a self-managed GitLab instance and send it one crafted request. From there, researchers who reproduced the bug found they could delete entire repositories. They could forge merge records too, making it look like a fix had landed when it hadn’t. They could even remove project maintainers from their own repositories.

A second, related flaw fixed in the same release, CVE-2026-19650, is a cross-site request forgery bug. It affects how GitLab handles bundled GraphQL queries and scores 7.1. An attacker could trigger changes through a GET request under the right conditions, but it needs a victim to click something first. That makes it less urgent than the main flaw, though the fix ships in the same update.

From disclosure to attack in 48 hours

GitLab shipped fixed versions, 19.2.4, 19.1.6, 19.0.8 and 18.11.11, alongside its advisory on 17 August. GitLab.com and GitLab Dedicated were already running the patched code. So only self-managed installations needed to act.

Many hadn’t, by the time attackers came looking. WatchTowr said it reproduced the GitLab GraphQL vulnerability within minutes of the advisory going public. It used nothing more than the patch notes and the version diff. Roughly two days later, its honeypot network recorded live exploitation attempts. One researcher at the firm put it bluntly: this is the new normal. AI-assisted attackers can turn a public advisory into working exploit code faster than most IT teams can schedule a maintenance window.

That speed is the real story here, more than the bug itself. GitLab’s security team did its job well. A bug bounty researcher found the flaw. GitLab fixed it and shipped an update outside its normal release schedule. The exposure window came afterwards, in the gap between the patch existing and organisations actually installing it. It’s the same pattern behind several other critical patches that turned into fast exploitation once attackers reverse-engineered the fix.

Why this matters beyond developers

GitLab isn’t just a tool for programmers. Businesses use self-managed instances to store source code, CI/CD pipelines and internal documentation. Often they hold credentials and configuration files too, referenced by build scripts. A repository quietly deleted, or a merge record quietly forged, can hide a much bigger problem. It could be a backdoor slipped into a build, or evidence of a breach erased before anyone notices.

For a business that relies on its GitLab instance for software releases, that’s not just an IT inconvenience. It’s a supply chain risk that reaches customers directly.

What to do now

If your organisation runs a self-managed GitLab CE or EE instance, treat the GitLab GraphQL vulnerability as urgent, not routine patching:

• Upgrade to 19.2.4, 19.1.6, 19.0.8 or 18.11.11, whichever matches your current branch, as soon as possible.
• If you can’t patch immediately, restrict unauthenticated access to the /api/graphql endpoint at the network or reverse-proxy level.
• As a last resort, turn off public project visibility until the upgrade is done.
• Check web server and application logs for requests referencing gl_introduced, a pattern researchers linked to probing for this flaw.
• Review recent merge history on public repositories for anything that looks forged or backdated, since the bug allowed records to be rewritten.
• Confirm your backups are current and kept somewhere this attack path can’t reach.

None of this needs specialist tooling. It’s the same patch management discipline that should already sit behind any internet-facing application. Patch fast, log everything, and check your own history whenever a vulnerability touches integrity as well as access. The GitLab GraphQL vulnerability is a sharp reminder of why that discipline matters, not an exception to it. Because the flaw needed no credentials, ordinary account security controls like multi-factor authentication offered no protection here, so the patch itself was the only real defence.