- Severity: CVSS 9.4 (Critical)
- Affected: GitLab CE/EE 18.2 through vulnerable 19.2 releases
- Patched: August 17, 2026 · Exploitation: No verified public PoC or confirmed in-the-wild exploitation
Introduction
GitLab has released an out-of-band critical security update for CVE-2026-19478, a code injection vulnerability in the GraphQL API affecting self-managed GitLab Community Edition (CE) and Enterprise Edition (EE).
Tracked as CWE-94: Improper Control of Generation of Code, the vulnerability can, under conditions GitLab has not yet disclosed, allow an unauthenticated remote attacker to modify or delete public projects and user data through a GraphQL directive. It carries a CVSS score of 9.4, with no privileges or user interaction required.
GitLab.com and GitLab Dedicated are already patched, so this is primarily a problem for self-managed GitLab administrators.
A GraphQL API where an anonymous visitor can potentially start modifying or deleting things is somewhat outside the usual definition of “read-only guest access.” :/
Attribution note: GitLab credits security researcher hiimguardian for reporting the vulnerability through its HackerOne bug bounty program. No detailed researcher writeup is public at the time of writing.
What Happened
CVE-2026-19478 involves code injection through a GraphQL directive. GitLab has deliberately kept the technical details limited while installations have time to patch, including the name of the vulnerable directive and the exact conditions required for exploitation.
What GitLab has confirmed is serious enough: a successful attack can remotely modify or delete public projects and user data without authentication.
It is also worth being precise about the phrase “code injection” Although the CVE is classified as CWE-94, GitLab has not stated that the vulnerability provides arbitrary operating-system command execution or full server RCE. The publicly documented impact is currently limited to modification or deletion of GitLab data.
No verified functional public exploit was identified as of August 18, 2026. A repository currently appearing in exploit aggregators is marked by its author as a Draft/TODO and contains only generic template material rather than a working exploit.
So, no, we’re not going to invent a payload and call it “technical analysis” GitLab hasn’t shown us the interesting part yet.
Why This Is Especially Dangerous
GitLab’s own CVSS vector tells most of the story: network exploitable, low attack complexity, no authentication and no victim interaction.
A successful attacker may be able to:
- Modify public project data without credentials.
- Delete public projects.
- Modify or delete affected user data.
- Cause significant integrity and availability damage remotely.
Internet-facing self-managed GitLab instances with public projects deserve particular attention. Git repositories frequently sit near the centre of development workflows, so destructive access can quickly become more than “just a website problem.”
Affected Versions
| Branch | Vulnerable Versions | Fix Available |
|---|---|---|
| 18.x | 18.2 through versions before 18.11.11 | 18.11.11 |
| 19.0 | Versions before 19.0.8 | 19.0.8 |
| 19.1 | Versions before 19.1.6 | 19.1.6 |
| 19.2 | Versions before 19.2.4 | 19.2.4 |
GitLab’s affected range begins with 18.2. Earlier releases are not listed as affected by this particular CVE, although running an unsupported GitLab release obviously isn’t a security strategy.
GitLab.com and GitLab Dedicated are already patched and require no customer action. All self-managed deployment types are affected unless otherwise specified by GitLab.
Mitigations
1. Upgrade immediately
Self-managed installations should update to one of the fixed releases:
- GitLab 19.2.4
- GitLab 19.1.6
- GitLab 19.0.8
- GitLab 18.11.11
GitLab explicitly recommends upgrading affected installations as soon as possible.
2. Don’t wait for the full exploit details
GitLab says vulnerability issues are made public 90 days after the release containing the fix. Waiting for that disclosure gives attackers the same additional information it gives defenders.
3. Restrict exposure if patching is delayed
GitLab has not published a vulnerability-specific workaround. If immediate upgrading is genuinely impossible, temporarily limiting access to the self-managed instance and its GraphQL API from untrusted networks can reduce exposure, but it should not be considered a replacement for patching.
Indicators of Compromise
GitLab has published no CVE-specific IoCs for CVE-2026-19478 as of August 18, 2026, and there is no confirmed exploitation campaign to hunt for.
Until more technical detail becomes public, defenders can look for behavioural anomalies instead.
On the instance
- Unexpected deletion or modification of public projects.
- Unexplained changes to user data.
- Administrative or audit events that do not correspond to known user activity.
In traffic logs
- Suspicious or unusually high volumes of requests to GitLab’s
/api/graphqlendpoint. - GraphQL requests from unfamiliar external sources shortly before project or user changes.
- Unusual GraphQL directive usage, particularly once GitLab discloses the affected directive.
Configuration and data integrity
- Verify important public repositories and project settings against known-good state.
- Review recent unexpected project and user changes.
- Confirm backups are current and recoverable in case destructive activity is discovered.
GitLab’s disclosure should be monitored for updated technical details and indicators as the vulnerability moves through its coordinated disclosure window.