We covered CVE-2026-19478 when GitLab patched it off-schedule and noted there was no known exploitation at the time. That has changed, and faster than the piece anticipated.
watchTowr reports reproducing the vulnerability within minutes of disclosure, and subsequently observing in-the-wild exploitation against its honeypot network.
What an attacker can actually do
The original advisory described modifying or deleting public projects. watchTowr's analysis extends that, and the extension is worse than the original:
- Delete entire repositories
- Forge merge records, so it appears a fix landed when it did not
- Ban project maintainers
The middle one deserves its own paragraph.
Destroying a repository is loud. Somebody notices within the hour, the backups come out, and the incident begins. Fabricating a merge record is silent, and it corrupts the thing every downstream process trusts: the record of what was changed and when. A team looking at its own history to confirm a security patch was merged would see the merge. Auditors would see the merge. The fix would not be there.
That inverts the usual relationship with a version control system. Git history is what everyone falls back on to establish ground truth after an incident. Here the history is the artefact under attack.
Banning maintainers is the operational companion to it — remove the people who would notice, then edit the record.
The timeline is the argument
| Date | What happened |
|---|---|
| 17 Aug 2026 | GitLab ships patches outside its normal release schedule |
| 18 Aug 2026 | GitLab reports no known exploitation, no public exploit code |
| Within days | watchTowr reproduces in minutes; in-the-wild exploitation observed |
Jake Knott, principal security researcher at watchTowr, puts the general point directly: this is the new reality of vulnerability reproduction, where AI-enabled attackers compress the time from disclosure to exploitation.
Treat that as a claim about a trend rather than a measurement — nobody has published evidence that AI specifically produced this exploit. What is measurable is the interval, and the interval is days.
The practical consequence is that GitLab's 90-day technical-disclosure convention protects nothing here. It was designed for a world in which reverse-engineering a patch took longer than deploying it. The patch diff is public the moment the release ships.
What to do now
- Patch to 19.2.4, 19.1.6, 19.0.8 or 18.11.11. This is no longer a scheduled task.
- If you cannot patch today, restrict unauthenticated access to /api/graphql, or remove public repository access entirely. Either breaks the precondition.
- Hunt your logs for requests containing @gl_introduced. watchTowr names this specifically. It is a cheap, precise search and you should run it before you finish reading.
- Verify your recent merges against a source that is not the instance. Developers' local clones, CI build records and artefact registries were not editable through this flaw. If the instance says a fix merged, check that the code is in a build.
- Check whether any maintainer lost access recently and nobody could explain why.
- Confirm a restore works. Deletion is the other half of this, and an untested backup is not a backup.
What is not established
- How many instances have been hit. watchTowr reports honeypot observation, not a victim count.
- Whether any real project's history has been forged. The capability is demonstrated; no confirmed case has been published.
- Whether AI was involved in building the exploit. That is an assessment of a trend, not a finding about this exploit.
- Whether it is in CISA's exploited catalogue. Not at the time of writing.
