A critical, unauthenticated code-injection flaw in self-managed GitLab is being actively exploited barely two days after the company shipped an emergency fix, giving remote attackers a way to delete or silently rewrite public source-code repositories without credentials or user interaction. GitLab patched the bug, tracked as CVE-2026-19478 and rated 9.4 on the CVSS scale, on August 17, 2026. Exposure-management firm watchTowr confirmed exploitation attempts hitting its honeypot network within days of disclosure, saying it was able to reproduce the exploit itself within minutes.
Context
The flaw sits in how GitLab’s GraphQL API handles a specific directive, allowing an unauthenticated attacker to send a single crafted HTTP request that deletes a publicly accessible project or rewrites its state, including forging merge records to fake a fix or removing legitimate maintainers. It affects self-managed GitLab Community and Enterprise Edition installations on versions 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.com SaaS and GitLab Dedicated were already running patched builds and are not affected.
The bug was reported through GitLab’s HackerOne bug bounty program and fixed in an out-of-band release outside the company’s normal monthly cadence, a sign of how severely it was assessed internally. Defenders should hunt web and access logs for requests containing the string @gl_introduced, which watchTowr flags as an indicator of probing or exploitation attempts.
Why It Matters for These Sectors
Self-managed GitLab is disproportionately favoured by organisations with strict data-residency or air-gap requirements: regulated financial institutions, telecom operators, and critical-infrastructure engineering teams that cannot use SaaS source control for compliance or network-isolation reasons. For these environments, GitLab is often the single system of record for application code, infrastructure-as-code, and CI/CD pipeline configuration.
An attacker who can silently delete or rewrite repository state, and mask the tampering by forging merge history, creates both an availability risk (lost engineering work, broken build pipelines) and an integrity risk (undetected code tampering feeding downstream deployments). Because the flaw requires no authentication and can be triggered in a single request, it is trivially scriptable. The two-day gap between patch and observed exploitation reflects how quickly opportunistic scanning now follows disclosure of high-severity CVEs affecting internet-facing developer infrastructure.
Recommended Actions
- Upgrade self-managed GitLab CE/EE immediately to 19.2.4, 19.1.6, 19.0.8, or 18.11.11.
- If immediate patching isn’t possible, restrict unauthenticated access to the
/api/graphqlendpoint or disable public project visibility as an interim mitigation. - Search web and access logs for requests containing
@gl_introducedto identify probing or exploitation attempts. - Audit recent merge and deletion activity on public-facing repositories for unexplained changes, particularly forged or out-of-process merge records.
- Treat this as a potential supply-chain integrity event rather than just an availability issue: validate recent build artifacts and CI/CD pipeline configurations if exploitation is suspected.