GitLab's 9.4 GraphQL bug went from patch to in-the-wild traffic in about two days

GitLab fixed CVE-2026-19478 on August 17, a code injection flaw rated CVSS 9.4 that the vendor said could let an unauthenticated user remotely modify or delete public projects and user data via a GraphQL directive ^{[1] [2]}. Attack surface management company WatchTowr says exploitation began roughly two days after public disclosure, which puts live attack traffic inside the window most self-managed teams use to schedule a maintenance slot ^{[3] [11]}.

The speed is the finding, not the bug class. WatchTowr told SecurityWeek that it reproduced the vulnerability within minutes of disclosure, armed only with the advisory details and the patch, and that no public exploit code was available at the time ^[6]. Its August 18 warning, one day after the fix shipped, already described the flaw as easily reproduced and urged self-managed operators to update immediately ^{[5] [12]}. On Wednesday the firm said its honeypot network had caught the first in-the-wild attempts against the CVE ^[4].

What an attacker gets is unusually clean. According to WatchTowr principal security researcher Jake Knott, an unauthenticated attacker can delete publicly accessible GitLab projects and rewrite their state, including deleting repositories outright, forging merge records, or banning maintainers, in a single HTTP request with no credentials, no user interaction, and no obscure configuration ^[9]. Knott frames the narrow patch window, driven by the severity of the bug and the use of AI, as the new baseline for reproduction and exploitation ^[13]. His colleagues' earlier phrasing was blunter: AI-enabled attackers are unlikely to be far behind a firm that needed minutes ^[6].

Mondoo co-founder and CSO Patrick Muench argues the forged merge records matter more than the deletions, because they could feed the next wave of supply chain attacks ^[14]. In every supply chain worm his team tracked this year, he said, attackers had to work around code review because faking an approval was harder than dodging it, and this flaw does it for free: a malicious change can look reviewed and signed off by someone the team trusts, the pipeline builds it and ships it downstream, and the audit log corroborates the whole thing ^[15]. "Deleting a repo costs you a bad afternoon. Forging trust in it costs you every release that follows," Muench said ^[15].

The remediation is specific. Fixes landed in GitLab Community Edition and Enterprise Edition 19.2.4, 19.1.6, 19.0.8, and 18.11.11 ^[7]. Where patching cannot happen now, WatchTowr's suggested mitigations are restricting unauthenticated access to the /api/graphql endpoint or removing public repository access entirely ^[8]. Anyone still unpatched should hunt web logs for requests containing "@gl_introduced" and look for probes or attempted exploitation, the company said ^[10].

Two things to watch. First, whether public exploit code appears, since the observed attempts arrived without it and a released proof of concept would widen the pool of operators beyond those who can read a diff ^{[6] [4]}. Second, whether anyone finds evidence of forged merge records rather than deleted repositories, because the destructive case announces itself and the fraudulent-approval case does not ^[15]. If your GitLab instance is self-managed, internet-reachable, and hosts public projects, the log search is the cheaper half of the job ^{[1] [8]}.