GitLab Patched It Monday. Our Harvester Had the Exploit Endpoints Tuesday. watchTowr Saw It Hitting Honeypots Friday. It Is Still Not in KEV. Here Is What to Grep.
- Patrick Duggan
- 2 hours ago
- 5 min read
[CVE-2026-19478](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19478) is a code-injection flaw reached through a GraphQL directive in GitLab Community and Enterprise Edition. CVSS 9.4. Unauthenticated, remote, no user interaction. An attacker who has never logged in can modify or delete user data and public projects.
GitLab patched it on 17 August 2026. Our exploit harvester collected public proof-of-concept code and emitted detection rules for it on 18 August. watchTowr reported it being exploited in the wild against their honeypot network on 21 August.
Today is 24 August, and it is not in the CISA Known Exploited Vulnerabilities catalogue.
The receipt, with both timestamps
We have a hard rule that no lead claim ships without the external comparator sitting beside our own timestamp, because we published a false one in July and had to correct it in public. So here is the whole ledger, including the row where we lose.
Date and time | Source | |
GitLab publishes the patch and advisory | 17 Aug 2026 | vendor — they were ahead of us, we claim nothing here |
Our harvester processes the first PoC repositories, emits detection rules | 18 Aug 2026, 00:01 and 12:01 UTC | exploit-harvester — first-party |
watchTowr reports in-the-wild exploitation on its honeypots | 21 Aug 2026 | comparator |
Our harvester collects a second, independent PoC repository | 22 Aug 2026, 18:01 UTC | exploit-harvester — first-party |
CISA KEV listing | not as of 24 Aug 2026 | checked today |
The defensible claim is the narrow one: our detection rules existed three days before the public in-the-wild report. The receipt is first-party — our own GitHub-harvesting cron, running on a schedule, writing a timestamp we did not choose — and it is a proof-of-concept-weaponisation lead, not a discovery. GitLab found the bug. Researchers wrote the exploits. We watched the weaponisation wave and wrote down what it targeted.
That is the lead type we can actually defend, and it is worth being precise about it, because the industry is full of vendors quoting an ingest timestamp as though it were a detection. If our record had said source: STIX-Ingest we would be calling this corroboration, not a lead. It does not. It says exploit-harvester.
Grep tonight. It is free and it takes ten minutes.
This is the useful half, and it is the reason we extract endpoints out of proof-of-concept code rather than just counting repositories.
Our harvester pulled these target paths out of the exploit code at confidence 85: /api/graphql, /api/v4/version, /users/sign_in, /subgroup/project, and /destroy/delete.
Pair those with the string watchTowr called out — @gl_introduced — and you have the attack in a single log line. A POST to /api/graphql carrying that directive, from a session that never authenticated, is what this looks like on the wire.
Go and grep your GitLab access logs and your reverse-proxy logs for @gl_introduced right now, across as much history as you keep. The bug was disclosed a week ago and reproduced by researchers within minutes of disclosure, so a week of history is the minimum useful window and a month is better.
If you run gitlab.com or GitLab Dedicated, you are already patched and this is not your problem. This is a self-managed-installation story, which means it is a story about the on-premise GitLab that some team stood up four years ago and that now holds every deploy key you own.
Patched versions: 19.2.4, 19.1.6, 19.0.8, and 18.11.11. Affected: 18.2 up to 18.11.11, 19.0 up to 19.0.8, 19.1 up to 19.1.6, and 19.2 up to 19.2.4.
Why "delete public projects" is worse than it sounds
The headline framing on this bug has been modify or delete user data and public projects, which reads like vandalism. Consider where a self-managed GitLab actually sits.
It holds your source. It holds your CI configuration, which is to say it holds a description of how code becomes production. It holds runner tokens and deploy keys. And it is trusted by every pipeline downstream of it, because the whole point of the thing is that pipelines trust it.
An unauthenticated write primitive against that is not a defacement risk. It is a supply-chain position. We have spent this year writing about attackers who compromise a maintainer's account to publish a poisoned package, and the shortest path to that outcome is a write primitive on the forge itself.
The pattern this is the newest instance of
We run a detector that measures weaponisation latency — the distance between a CVE being published, the first public exploit landing, and CISA cataloguing it. The finding that made us build it: of 86 KEV entries we examined, 15 were already armed with public exploit code before CISA listed them.
This one is a step past that. It is armed, it is confirmed exploited in the wild by a named research team, and it is still not catalogued.
That is not CISA being slow, and we are not going to pretend it is. KEV requires evidence of active exploitation meeting their bar, and holding that bar is the entire reason the catalogue is worth reading. Both instruments are doing their jobs. But the arithmetic falls out the same way regardless of whose fault it is: if your patch prioritisation runs on KEV alone, you begin moving on a bug some interval after the exploit became publicly downloadable, and on this bug that interval is now at least seven days and still counting.
Watch the proof-of-concept wave, not just the catalogue. We publish ours free, for exactly this reason.
Sources
CVE-2026-19478, CVSS 9.4, code injection via GraphQL directive in GitLab CE/EE, patched 17 August 2026 in 19.2.4, 19.1.6, 19.0.8 and 18.11.11. In-the-wild exploitation reported by watchTowr, covered 21 August 2026; the @gl_introduced hunting string is theirs. KEV status checked against our cisa_kev index on 24 August 2026.
The PoC collection timestamps, the extracted endpoint list and the confidence scores are from our own exploit-harvester, in the iocs index under source=exploit-harvester.
Capped at 95 percent as always: we have no first-party telemetry of a successful compromise against a real GitLab instance, our repository count is what one harvester pass saw and there may well be more exploits published than we collected, and KEV listings can land at any hour — if it is catalogued between our check and your read, our seven-day figure is the one that goes stale, not the advice.
If you grep for @gl_introduced tonight, tell me what came back. A clean result is genuinely as useful to publish as a dirty one, and almost nobody publishes the clean ones. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=gitlab-patched-it-monday-our-harvester-had-the-exploit-endpoints-tuesday-watchtowr-saw-it-hitting
Comments