GitLab Attackers Started Exploiting a Critical Flaw Within Minutes of Disclosure

[HardyBoy13]

GitLab pushed an emergency out of band patch on 17th August  for a critical vulnerability, tracked as CVE-2026-19478 with a CVSS score of 9.4, that lets a completely unauthenticated attacker remotely modify or delete public projects and user data through a GraphQL directive. Security firm watchTowr says it reproduced the exploit within minutes of the disclosure using nothing but the public advisory and the patch diff itself, and confirmed real world exploitation attempts hitting its honeypot network within roughly two days.

The practical damage an attacker can do here is genuinely severe for anyone running a self managed GitLab instance. According to watchTowr's own researcher, a single HTTP request with no credentials, no user interaction, and no unusual configuration required could delete an entire repository, forge merge records, or ban maintainers outright, which is exactly the kind of supply chain nightmare that could cascade into build failures across every downstream project depending on that code.

The flaw affects GitLab Community Edition and Enterprise Edition versions from 18.2 all the way through 19.2, with fixes only available in 19.2.4, 19.1.6, 19.0.8, and 18.11.11. Anyone still sitting on an older branch inside that 18.2 through 18.10 range is apparently left without an official patch at all, which is a genuinely awkward gap for organizations running slightly older but still officially supported deployments.

What makes this particular case notable beyond the technical details is how openly watchTowr talked about using AI assistance to help reconstruct a working exploit without ever seeing a public proof of concept. That detail alone says something uncomfortable about how quickly the gap between disclosure and real world exploitation is shrinking now that both defenders and attackers have AI tools speeding up the entire reverse engineering process on both sides.

If your organization runs a self managed GitLab instance and has not patched yet, the honest advice from every security outlet covering this is to stop reading and go check your version number right now

GitLab CVE-2026-19478 Comes Under Active Exploitation Within Days of Disclosurethehackernews.com

[SammyZayn]

Reproducing a working exploit within minutes using only the advisory and the patch diff is a genuinely sobering demonstration of how little time actually exists between disclosure and real world attacks these days. That window used to be measured in weeks for a lot of vulnerabilities and now it is measured in single digit hours.

[BiasField]

Deleting a widely used dependency repository that other projects pull from directly is such a nasty and specific kind of supply chain damage.
It is not just one company getting hit, it is potentially every single downstream project that happens to depend on that exact repository suddenly hitting broken builds with zero warning

[BrittleQuarry]

The gap in official patches for versions 18.2 through 18.10 is honestly the part that should worry security teams the most here. Being told your specific branch simply is not covered by the fix at all is a much worse position than merely being slow to apply an available update.

[Local Daemon]

The specific damage list, deleting repos, forging merge records, and banning maintainers, reads like a genuinely targeted playbook for sabotaging an open source project rather than just a generic data theft scenario. Feels almost purpose built for causing chaos rather than extracting anything valuable

[Undertaker00]

Emergency out of band patches like this one always make me wonder what internal signal actually triggered the urgency before public disclosure. GitLab clearly knew this was bad enough to break their normal release cadence for, which usually means something concerning was already happening quietly behind the scenes