Attackers don’t need credentials or user interaction to exploit the flaw which could enable supply chain attacks in self-hosted code repositories.
GitLab has fixed a critical vulnerability that could allow unauthenticated attackers to perform unauthorized modifications inside code repositories or to completely delete them with a single HTTP request. The patched releases also address a second high-risk cross-site request forgery (CSRF) flaw.
The critical vulnerability, tracked as CVE-2026-19478, is described as a code injection issue through the GraphQL directive and was reported privately to GitLab through its bug bounty program on HackerOne.
However, even if the flaw’s details are not yet public, researchers from security firm watchTowr warn that it’s extremely easy to reverse-engineer the patches and build an exploit.
“WatchTowr was able to reproduce the vulnerability within minutes of its disclosure, armed only with the advisory details and patch,” Jake Knott, principal security researcher at watchTowr, tells CSO. “AI-enabled attackers are unlikely to be far behind.”
GitLab is a popular source code management system and DevOps platform, complete with CI/CD pipelines and security scanning. The fact that users can self-host it on their own servers makes it an attractive alternative to GitHub, especially for organizations, which is why the software comes in two variants, a free Community Edition (CE) and a paid Enterprise Edition (EE).
The code injection vulnerability is very dangerous especially for GitLab instances exposed directly to the internet because it can lead to software supply chain attacks. The flaw allows attackers to rewrite the state of GitLab repositories, forge merge records, ban maintainers, and even delete entire projects. The exploit doesn’t require credentials, user interaction, or special configurations.
GitLab released versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 for both CE and EE editions to patch CVE-2026-19478 and CVE-2026-19650, a CSRF issue in the GraphQL multiplex query handler.
Users who can immediately deploy the patches are advised to make their repositories private and to block unauthenticated access to the /api/graphql endpoint.
Updated August 19:
On Wednesday, watchTowr started seeing in-the-wild exploitation of this vulnerability across its honeypot network. Organizations can check their logs for requests that contain the string “@gl_introduced” which could indicate exploitation attempts.
“This is the new reality of vulnerability reproduction and exploitation, where AI-enabled attackers are able to compress the time from disclosure to exploitation and ‘waiting until the next patch cycle’ is often too late,” Knott told CSO.
