Critical GitLab Code Injection Vulnerability Actively Exploited in Attacks

GitLab administrators are being urged to patch immediately after security researchers observed attempts to exploit CVE-2026-19478, a critical unauthenticated code injection vulnerability affecting self-managed GitLab Community Edition and Enterprise Edition instances.

The flaw, rated 9.4 out of 10, can allow remote attackers to modify or delete public projects and associated user data through GitLab’s GraphQL interface. GitLab issued an out-of-band update on August 17, 2026, outside its regular security release schedule.

The issue stems from improper handling of a GraphQL directive, which can be abused under specific conditions without requiring an account, authentication, or user interaction. This makes internet-facing GitLab deployments especially exposed.

Security firm WatchTowr reported that it reproduced the vulnerability within minutes of disclosure by analyzing GitLab’s public advisory and the vendor’s patch changes. Researchers said the practical impact may extend beyond GitLab’s short description of unauthorized modification or deletion.

An attacker could reportedly remove repositories, manipulate merge-related records to create a misleading appearance that changes were merged, or ban legitimate maintainers from public projects.

GitLab Code Injection Vulnerability

Exploitation activity has already been detected in the wild. watchTowr said its Attacker Eye honeypot network recorded attempts to exploit the vulnerability shortly after the disclosure, indicating that attackers are rapidly testing exposed GitLab instances.

While public technical details and proof-of-concept activity can accelerate weaponization, the main risk is the flaw’s pre-authentication access and low barrier to remote exploitation.

The vulnerability affects GitLab CE and EE versions 18.2 through 18.11.10, 19.0 through 19.0.7, 19.1 through 19.1.5, and 19.2 through 19.2.3. GitLab has released patched builds 18.11.11, 19.0.8, 19.1.6, and 19.2.4.

GitLab patched GitLab.com and GitLab Dedicated, and no customer action is required. However, organizations running self-managed GitLab installations must upgrade without delay.

Where an immediate upgrade is operationally difficult, defenders should identify internet-exposed instances, review whether public projects are enabled, and restrict access to the GraphQL endpoint via network controls or a reverse proxy until patching is complete.

Security teams should also review recent GraphQL activity, repository deletions, unexpected project modifications, suspicious changes to merge records, and unexplained maintainer access restrictions.

Given confirmed attempts at exploitation, organizations should treat exposed, unpatched GitLab servers as potentially compromised and preserve relevant logs before remediation.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC