A critical flaw in GitLab, one of the most widely used platforms for hosting and managing software code, is already being exploited by attackers just days after it was disclosed and patched.
This is a developing update to our earlier coverage of GitLab’s patch for this flaw, published on August 18, when no evidence of exploitation in the wild had yet emerged.
The vulnerability, tracked as CVE-2026-19478, carries a CVSS score of 9.4 out of a possible 10. GitLab described the issue in its own advisory as a problem that, under certain conditions, could allow “an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive.” GraphQL is a query language many web applications, including GitLab, use to let software request specific pieces of data from a server. A flaw in how that request is processed here meant an attacker did not need a username, password, or any special setup to abuse it.
According to security researchers, the attack works with a single HTTP request, the same basic type of message a web browser sends every time someone loads a page. No credentials, no user interaction, and no unusual configuration were required. Once exploited, an attacker could delete entire public repositories, forge merge records to make it look like a code fix had been applied when it had not, remove or ban project maintainers, and otherwise rewrite the state of a project.
GitLab released fixes for the issue on August 17 in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 of both its Community Edition and Enterprise Edition. That patch turned out to buy very little time. WatchTowr, an attack surface management firm, said it was able to reproduce the vulnerability within minutes of the disclosure using nothing more than the public advisory and the patch itself. Two days later, on August 19, the company detected the first real attack attempts against its own honeypot network, systems deliberately set up to look like vulnerable targets in order to catch and study attackers.
Jake Knott, a principal security researcher at watchTowr, said the speed of this exploitation reflects a broader shift in how quickly attackers can move once a vulnerability becomes public, pointing to the growing role of AI-assisted tools in compressing the gap between disclosure and real-world attacks.
Because the flaw specifically affects publicly accessible GitLab projects, organizations that host open source code or other public repositories on self-managed GitLab instances face the most direct exposure. GitLab.com, the company’s own hosted service, applies patches centrally, so the greater risk sits with organizations running their own GitLab servers that have not yet applied the update.
Security researchers recommend that administrators who cannot patch immediately restrict unauthenticated access to the “/api/graphql” endpoint, or remove public repository access entirely until the update is installed. Reviewing web server logs for requests containing the string “@gl_introduced” can help identify whether exploitation attempts have already occurred.
As of publication, GitLab has not disclosed how many organizations were affected before the patch was released, and no figure for successful compromises tied to this specific campaign has been made public. Administrators running self-managed GitLab instances are advised to update immediately if they have not already done so.
Related coverage: GitLab Fixes Critical Flaw That Let Anyone Delete Public Projects Without Logging In (August 18, 2026).
Source: The Hacker News, with additional reporting from SecurityWeek.
[…] Critical GitLab Vulnerability Already Under Attack Days After Patch Release […]