Critical GitLab flaw lets hackers delete or rewrite repositories – now exploited in wild

GitLab is urging users to immediately patch a newly discovered critical flaw that can allow unauthenticated attackers to remotely modify and delete repositories and user data.

What’s more, the 9.4-rated vulnerability (CVE-2026-19478) can be exploited on self-hosted GitLab systems without any interaction – and all through just one specially crafted GraphQL request.

GitLab flaw already being exploited in the wild

Updated August 19th: Barely 24 hours after GitLab disclosed the new vulnerability, watchTowr researchers say attackers are already attempting to exploit it in the wild.

As expected, one day later – and we are already seeing in-the-wild exploitation of this vulnerability hit our global Attacker Eye honeypot network,”

watchTowr Principal Security Researcher Jake Knott tells Cybernews.

Knott says the rapid turnaround is the harsh truth defenders are now facing as AI tools dramatically shrink the window between vulnerability disclosure and actual exploitation.

“This is the new reality of vulnerability reproduction and exploitation, where AI-enabled attackers are able to compress the time from disclosure to exploitation and ‘waiting until the next patch cycle’ is often too late,” he said.

Organizations that have not yet patched should search web logs for requests containing “@gl_introduced” and look for signs of probing or attempted exploitation, Knott added.

GraphQL is one of the API query languages that GitLab uses. A GraphQL query essentially instructs the GitLab server on how to carry out the task it is given.

Critical GitLab flaw needs no user interaction

Knott says that besides deleting publicly accessible GitLab projects and rewriting their state, attackers could also “delete entire repositories, forge merge records, or ban maintainers in a single HTTP request with no credentials, user interaction, or obscure configuration required.”

Although no public exploit was known to exist before Tuesday, watchTowr researchers say they were able to reproduce the code injection exploit within minutes – and “armed only with the advisory details and patch.”

At the time, Knott told Cybernews that “AI-enabled attackers are unlikely to be far behind" – a prediction that would prove true less than a day later.

“It's only Tuesday, and we're already dealing with a critical out-of-band security patch for GitLab instances, and yet again another reminder that supply chain attacks can take many shapes and sizes,"

Knott said.

GitLab Self-Managed users urged to update

WatchTowr researchers have warned defenders to "upgrade self-managed instances now, or restrict access to ‘/api/graphql’ where possible.”

GitLab, which disclosed the flaw and its fix on Monday, says affected GitLab Community Edition (CE) and Enterprise Edition (EE) versions include:

• 18.2 through 18.11.10
• 19.0 through 19.0.7
• 19.1 through 19.1.5
• 19.2 through 19.2.3

The San Francisco-based company is urging users to immediately upgrade to patched versions 18.11.11, 19.0.8, 19.1.6, or 19.2.4.

“These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately,”

the developer collaboration platform said.

Notably, GitLab.com and GitLab Dedicated are already running the patched version, meaning customers of those platforms do not need to take action.

Forged merge records pose bigger supply chain risk

Patrick Münch, co-founder and Chief Security Officer (CSO) at Mondoo says that "supply chain attacks have been climbing hard for the past year,” while also pointing out that "the pattern behind them barely changes."

Citing the recent Shai-Hulud and GlassWorm-fueled malware campaigns, Münch says these attacks all abuse the same thing: “the implicit trust we put in our developer identities and our pipelines.”

Münch describes the GitLab flaw as just “the next rung on that ladder”, noting that even if a repo is deleted, most developers will know within the hour and easily restore it from backup.

Forged merge records can have much larger (and lengthier) consequences, he says.

Previously, in supply chain attacks, threat actors were "forced to work around code review – now faking an approval becomes much easier," he explains.

“An attacker can make a malicious change look reviewed and signed off by someone your team trusts. Your pipeline builds it and ships it downstream, and your own audit log swears the whole thing was legitimate,”

Münch says.

“Deleting a repo costs you a bad afternoon. Forging trust in it costs you every release that follows," the CSO added.

GitLab awards researcher $26K bug bounty

In its announcement, GitLab also gave a shout-out to the researcher who discovered and reported the vulnerability on August 14th.

“Thanks hiimguardian for reporting this vulnerability through our HackerOne bug bounty program,” GitLab wrote.

According to Toronto-based researcher Connor Laidlaw’s HackerOne profile, this appears to be his first bug bounty documented through the program, netting the hunter a cool $26,010.

GitLab patches second GraphQL flaw

Along with the code injection flaw, GitLab also released a patch for a second GraphQL vulnerability (CVE-2026-19650).

With a CVSS high severity score of 7.1, GitLab says the flaw could allow an unauthenticated attacker to perform cross-site request forgery (CSRF) attacks.

Unlike the critical 9.4 flaw, exploitation requires user interaction.

Two researchers (kreep and diablosec) collaborated on finding the second bug, earning a much lower $5,530 bounty, as their profiles show.