GitLabGraphQLCVECI/CDtechnical

GitLab CVE-2026-19478: Unauthenticated GraphQL Injection Exploited Within 48 Hours

Name: CleanIssue
Price range: €€

Published on 2026-08-186 min readCleanIssue

> TL;DR: CVE-2026-19478 is a critical flaw (CVSS 9.4) in GitLab CE and EE enabling unauthenticated code injection through the GraphQL API. A remote attacker with no credentials at all can modify or delete public projects, fabricate fake merge records, or ban maintainers. A public PoC was exploited in the wild within two days of disclosure.

The flaw

The issue (CWE-94, code injection) stems from improper validation of a GraphQL directive. By sending a crafted GraphQL request containing this directive to an internet-facing GitLab instance, an attacker can:

Modify or delete public projects and repositories — including complete deletion.

Fabricate fake merge records, making it look like a security patch was merged when it wasn't.

Ban or remove project maintainers.

No authentication, no credentials, no user interaction required. That's a rare and particularly dangerous combination for a tool as central as GitLab within a CI/CD pipeline.

Affected versions

GitLab CE/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).

Exploitation timeline

Researchers at watchTowr and Horizon3.ai published a working proof of concept within minutes of public disclosure. In-the-wild exploitation was observed within 48 hours — an increasingly short window that reflects a broader trend: automation (sometimes AI-assisted) is accelerating how fast published PoCs get weaponized.

Detection indicator: check your web server logs for GraphQL requests containing the string @gl_introduced — a marker observed in known exploitation attempts.

Why this matters beyond DevOps teams

This flaw affects development infrastructure (self-hosted GitLab), not a consumer-facing SaaS application directly — but it illustrates a pattern we constantly see in GraphQL API audits: a directive or query field meant to be restricted to internal or administrative use isn't properly isolated from public access. The same design flaw (insufficient validation of exposed GraphQL directives and fields) shows up regularly in business-application GraphQL APIs, with similar consequences: data modification or deletion with no authentication whatsoever.

What to do

Update immediately to 18.11.11, 19.0.8, 19.1.6, or 19.2.4 depending on your branch.

If an immediate update isn't possible, restrict public access to /api/graphql or take public repositories offline temporarily.

Audit recent project history: unexpected merges, deletions, and maintainer role changes.

What CleanIssue checks for

During an API audit, we systematically test GraphQL endpoints and directives to verify that no modification or deletion operation is reachable without proper authentication — exactly the type of flaw exploited here.

Key takeaways

Any GraphQL directive or field with a mutating effect must be explicitly validated server-side, never assumed to be protected by schema complexity.

The gap between public disclosure and real-world exploitation is now measured in hours — a reactive patch management process is no longer optional.

A compromised development platform (GitLab, CI/CD) is a pivot point into your source code and deployment pipeline, not just an isolated risk.

Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.

Three adjacent analyses to keep exploring the same attack surface.

CVEAI & LLM

LiteLLM CVE-2026-42271: command injection via MCP endpoints, actively exploited

A flaw in the LiteLLM proxy (CVSS 8.8) lets any API key holder execute commands on the server through the MCP test endpoints. CISA confirms active exploitation. If your SaaS has AI features, read this.

2026-07-06 · 6 min read

GitLabDevOps