GitLab Flaw Exploited Within Days of Patch

Security teams are racing to patch a critical GitLab vulnerability that attackers have already begun exploiting in the wild, less than a week after the flaw was disclosed. The bug, tracked as CVE-2026-19478, carries a CVSS score of 9.4 and allows unauthenticated code injection capable of stripping or rewriting public projects.

According to watchTowr, a preemptive exposure management firm, the flaw is already being actively exploited, a development that underscores the shrinking window between disclosure and weaponization. The firm said it observed attacks against its honeypot network within days of the public advisory.

A Critical Code Injection Flaw

CVE-2026-19478 is a code injection vulnerability that affects both GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw enables an unauthenticated attacker to modify or delete publicly accessible GitLab projects and rewrite their data under certain conditions, all without requiring credentials, user interaction, or obscure configuration.

GitLab's advisory, released earlier this week, explained that the issue can be exploited via a GraphQL directive. The company has issued fixes in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11.

Affected Versions

The following GitLab CE and EE versions are vulnerable:

• 18.2 before 18.11.11
• 19.0 before 19.0.8
• 19.1 before 19.1.6
• 19.2 before 19.2.4

Organizations running any of these versions are advised to upgrade to the patched releases immediately. GitLab has also provided mitigations for those unable to patch right away.

Immediate Exploitation Observed

watchTowr told The Hacker News that it was able to reproduce the vulnerability within minutes of its disclosure, a testament to the ease of exploitation. The firm also reported observing in-the-wild attacks against its honeypot network, confirming that threat actors are actively targeting the flaw.

The speed of exploitation highlights a worrying trend: attackers are leveraging artificial intelligence to compress the time between disclosure and exploitation. This makes traditional patch cycles dangerously slow, as waiting for the next scheduled maintenance window may already be too late.

Beyond Simple Data Wiping

The impact of this vulnerability extends far beyond merely modifying or deleting public projects. watchTowr warned that an attacker can delete entire repositories, forge merge records to make it appear as if a fix landed when it didn't, and even ban project maintainers.

This level of access could allow an attacker to sabotage a project's codebase, trick maintainers into thinking vulnerabilities have been patched when they haven't, and lock the rightful owners out entirely. For organizations relying on GitLab for critical development workflows, the consequences could be severe.

Recommendations for Mitigation

In light of the active exploitation, GitLab users are urged to take immediate action. The primary recommendation is to upgrade to a patched release (19.2.4, 19.1.6, 19.0.8, or 18.11.11) without delay.

For organizations that cannot patch immediately, GitLab advises restricting unauthenticated access to the /api/graphql endpoint, or removing public repository access entirely as a temporary measure. Additionally, watchTowr suggests that organizations should hunt through web logs for requests containing the string '@gl_introduced' to look for signs of probes or attempted exploitation.

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

Knott's quote captures the urgency that security teams face in this new era of AI-driven attacks. The window to patch before exploitation is shrinking, and the traditional approach of deferring updates to a monthly maintenance window is no longer viable.

Why This Matters for Your Enterprise

The active exploitation of CVE-2026-19478 within days of disclosure signals a critical shift in the threat landscape. AI-enabled attackers are accelerating the timeline from public disclosure to weaponized exploit, leaving organizations with little time to react. For any business running self-hosted GitLab instances, the risk is not abstract — it is a direct threat to the integrity of source code and development pipelines.

The ability to forge merge records and ban maintainers could undermine a company's entire software supply chain, leading to the deployment of compromised code or the loss of critical intellectual property. This incident serves as a stark reminder that, in the age of automated attack tools, the only effective defense is to patch quickly — every single time.

If you haven't already, prioritize upgrading your GitLab instances today. The attackers are not waiting, and neither should you.