Skip to main content
Emerging Threats

GitLab Flaw Exploited in Wild Days After Disclosure

Server rack in a network operations room with rows of computer servers and equipment.
"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, said.

What watchTowr observed in the wild

Within minutes of public disclosure, watchTowr reproduced the newly announced flaw in GitLab and reported seeing in-the-wild exploitation against its honeypot network, the company told The Hacker News. The rapid reproduction and active probing—observed on internet-facing decoys—prompted a concrete recommendation from watchTowr to "hunt through web logs for requests containing '@gl_introduced,' and look for signs of probes or attempted exploitation."

Beyond simple modification or deletion of public projects, watchTowr said an attacker exploiting the flaw can delete entire repositories, forge merge records so it appears a fix landed when it did not, and ban project maintainers—escalations that amplify the operational and forensic impact on affected projects.

The vulnerability: CVE-2026-19478 and the attack vector

The bug is tracked as CVE-2026-19478 with a CVSS score of 9.4. GitLab described the issue as a case of code injection that allows an unauthenticated attacker to modify or delete publicly accessible GitLab projects and rewrite their data under certain conditions without requiring credentials, user interaction, or obscure configuration. GitLab additionally said the issue could be exploited via a GraphQL directive.

Because the flaw does not require authentication or user interaction, and because it can be triggered through GraphQL, the attack surface includes any internet-accessible endpoint that exposes GitLab's GraphQL API.

Patched releases and the affected versions

GitLab listed the affected Community Edition (CE) and Enterprise Edition (EE) versions as:

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

Fixes were rolled out in GitLab CE and EE versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11. Organizations running these releases or older should treat the updates as high priority given the vulnerability’s severity and confirmed exploitation.

Mitigations and recommended immediate steps for operators

GitLab and watchTowr converged on a short list of immediate measures for operators who cannot patch immediately. The primary mitigations are:

  • Prioritize upgrading internet-facing self-hosted GitLab instances to one of the patched releases listed above.
  • If immediate patching is impossible, restrict unauthenticated access to the "/api/graphql" endpoint to prevent GraphQL-based exploitation.
  • As a more disruptive fallback, remove public repository access entirely until the instance can be patched.

watchTowr’s guidance to search logs for requests containing the string "@gl_introduced" is designed to help defenders detect exploitation attempts or probes that followed publication of the vulnerability.

What this means for security teams, hosted GitLab operators, and adversaries

  • Security teams: Expect a compressed response window. The reproduction of CVE-2026-19478 "within minutes" and observed exploitation against honeypots underscore the need to triage, patch, and hunt in logs immediately after high-severity disclosures.
  • Hosted GitLab operators and enterprises running self-hosted instances: Prioritize applying the patched releases (19.2.4, 19.1.6, 19.0.8, 18.11.11) and, where that cannot be done quickly, implement the recommended mitigations—restricting /api/graphql or disabling public repositories—to reduce exposure.
  • Adversaries: watchTowr’s framing highlights a tactical change: AI-enabled tooling can reduce the time between disclosure and exploitation, enabling attackers to move from proof-of-concept to active abuse faster than traditional patch cycles allow.

For organizations that manage source code, repositories and project maintainers, the practical upshot is straightforward: a high-severity, unauthenticated code-injection bug has been weaponized quickly enough in the wild to make rapid patching the default, not the exception. The specific detection string ("@gl_introduced"), the GraphQL attack vector, and the list of patched releases give defenders concrete, immediate actions.

Link to original report: The Hacker News — GitLab CVE-2026-19478 Comes Under Active Exploitation Within Days of Disclosure