Actively Exploited GitLab Flaw Puts Public Projects at Risk

GitLab CVE-2026-19478, a critical code-injection vulnerability with a CVSS score of 9.4, is being actively exploited within days of its public disclosure. The flaw affects GitLab Community Edition and Enterprise Edition and can allow an unauthenticated attacker, under certain conditions, to modify or delete publicly accessible projects and rewrite their data without credentials, user interaction or obscure configuration.

GitLab said the vulnerability can be exploited through a GraphQL directive. watchTowr reported that it reproduced the issue within minutes of disclosure and subsequently observed exploitation attempts against its honeypot network.

Affected releases and available fixes

The affected version ranges are GitLab CE and EE 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. GitLab issued fixes in versions 18.11.11, 19.0.8, 19.1.6 and 19.2.4.

The risk extends beyond unwanted changes to public projects. watchTowr said an attacker could delete entire repositories, forge merge records to make it appear that a fix was merged when it was not, and ban project maintainers. Those outcomes could affect both code availability and the integrity of development records.

What defenders should examine

watchTowr advised organizations that remain unpatched to search web logs for requests containing @gl_introduced and investigate signs of probing or exploitation attempts. That guidance is particularly relevant for internet-facing, self-hosted GitLab deployments with public repositories.

The short interval between disclosure and observed activity follows the faster attack tempo described in AI-agent security incidents and vulnerability chains, where vulnerabilities and AI-agent incidents were part of the week’s security picture. Jake Knott, principal security researcher at watchTowr, said AI-enabled attackers can compress the time from disclosure to exploitation, making a wait for the next patch cycle potentially too late.

Immediate mitigation for self-hosted instances

Organizations running exposed GitLab servers should prioritize an upgrade to a patched release. If an immediate update is not possible, GitLab users can restrict unauthenticated access to /api/graphql or remove public repository access entirely as an interim mitigation.

The practical business implication is to treat this as an urgent maintenance and monitoring task: patch affected GitLab instances, review relevant web logs, and reduce unauthenticated GraphQL exposure until the update is complete.