A newly disclosed security flaw in GitLab has come under active exploitation within days of public disclosure, according to watchTowr.
The vulnerability in question is CVE-2026-19478 (CVSS score: 9.4), a case of code injection that allows an unauthenticated attacker to modify or delete publicly accessible GitLab projects and rewrite their data under certain conditions without requiring credentials, user interaction, or obscure configuration.
The following versions of GitLab Community Edition (CE) and Enterprise Edition (EE) are affected by the flaw –
- 18.2 before 18.11.11
- 19.0 before 19.0.8
- 19.1 before 19.1.6
- 19.2 before 19.2.4
In an alert released earlier this week, GitLab said the issue could be exploited via a GraphQL directive. Fixes for the flaw were rolled out in GitLab CE and EE versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11.
Preemptive exposure management firm watchTowr told The Hacker News that it was able to reproduce the vulnerability within minutes of its disclosure, adding that it observed in-the-wild exploitation against its honeypot network.
“This is the new reality of vulnerability reproduction and exploitation, where AI [artificial intelligence]-enabled attackers are able to compress the time from disclosure to exploitation and ‘waiting until the next patch cycle’ is often too late,” Jake Knott, principal security researcher at watchTowr, said.
“Organizations that haven’t patched yet should hunt through web logs for requests containing ‘@gl_introduced,’ and look for signs of probes or attempted exploitation.”
watchTowr also noted that the vulnerability’s impact goes beyond the ability to modify or delete public projects, adding “an attacker can delete entire repositories, forge merge records to make it appear as if a fix landed when it didn’t, and ban project maintainers.”
The development once again highlights how AI is rapidly changing the speed and the scale of the attacks, making it crucial that users apply the updates in a timely fashion.
Organizations running internet-facing self-hosted GitLab instances should prioritize upgrading to a patched release. If immediate patching is not possible, it’s advised to restrict unauthenticated access to “/api/graphql”, or remove public repository access entirely as a mitigation.
