GitLab CVE-2026-19478: Unauthenticated Repository Takeover, Exploited Within Days
Originally reported viaThe Hacker News — “GitLab CVE-2026-19478 Comes Under Active Exploitation Within Days of Disclosure” (21 August 2026) · watchTowr researchCVE-2026-19478 is a CVSS 9.4 code injection vulnerability in GitLab Community and Enterprise Edition, reachable through a GraphQL directive. It requires no credentials, no user interaction and no unusual configuration. An unauthenticated attacker who can reach the GraphQL API of a GitLab instance can modify, rewrite or delete any publicly accessible project on it.
The exploitation timeline is the part worth internalising. watchTowr, the exposure management firm that analysed the flaw, reproduced it within minutes of disclosure and subsequently observed in-the-wild attempts against its own honeypot network within days. The gap between a public advisory and working attacks in the wild has been shrinking for years; on this one it effectively closed.
What an attacker can actually do
The headline capability is destructive: an attacker can delete entire repositories. That is serious, but for most organisations it is also the recoverable outcome — mirrors, developer clones and backups exist. The consequences that matter more are the quiet ones. The same access allows an attacker to rewrite project data, forge merge records so that a fix appears to have shipped when it never did, and ban project maintainers to slow the response once the intrusion is noticed.
Forged merge records are the finding we would flag hardest in an incident review. A great deal of enterprise security process treats source control history as ground truth: patch verification, change management evidence, SOC 2 and NIS2 control attestation, and the audit trail that answers whether a specific vulnerability was actually remediated. If that history can be written by an unauthenticated party, every downstream assurance built on it is provisional until proven otherwise.
Affected and fixed versions
The vulnerability affects GitLab CE and EE across four release lines: 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. The corresponding fixed releases are 18.11.11, 19.0.8, 19.1.6 and 19.2.4. The breadth of the affected range matters — an instance held back on the 18.2 line for stability reasons is just as exposed as one a single patch release behind on 19.2.
Self-managed instances carry the entire risk here. Any organisation running its own GitLab — particularly the internet-reachable instances many companies maintain for contractors, open source projects or customer-facing repositories — needs to establish its version before anything else.
If your GitLab history can be rewritten anonymously, your patch evidence is a claim, not a record.
— Priya Kapoor, Vulnerability Research · Furix Feed
Detection and interim mitigation
There is a concrete hunting signal available. Exploitation involves the GraphQL directive, so web and reverse-proxy logs should be searched for requests containing the string '@gl_introduced'. Because the attack path is unauthenticated, these requests will appear without a session context — an anomaly in its own right against a GraphQL endpoint. Search the full retention window, not just the period since the advisory; the flaw existed before it was disclosed.
Where patching cannot happen immediately, restricting unauthenticated access to the /api/graphql endpoint at the reverse proxy or WAF removes the reachable path. Removing public repository access entirely is the stronger interim control, since the vulnerability's write primitive is scoped to publicly accessible projects. Both are stopgaps; neither is a substitute for the upgrade.
- Determine your GitLab version and upgrade to
19.2.4,19.1.6,19.0.8or18.11.11depending on your release line. Treat internet-reachable self-managed instances as an emergency change. - Block or authenticate /api/graphql at the proxy layer as an interim control if the upgrade window cannot be brought forward.
- Search web and proxy logs across your full retention period for requests containing '@gl_introduced', and for unauthenticated GraphQL requests generally.
- Verify the integrity of recent merge and commit history on public projects against independent mirrors or developer clones — do not assume the GitLab history is authoritative until the instance is confirmed clean.
- Re-confirm maintainer and owner membership on every public project. Unexpected removals are a documented part of the impact and are easy to overlook as routine access churn.
- Reduce the standing attack surface: audit which projects genuinely need to be publicly accessible, and place any GitLab instance that does not require internet exposure behind SSO or a VPN.
Stay ahead of the threat curve
Get the latest CVE advisories, threat actor intelligence, and detection engineering posts delivered to your inbox.
