Critical GitLab Flaw Lets Attackers Wipe Public Repos With No Login

GitLab has confirmed active exploitation of a critical vulnerability in its GraphQL API, just days after the flaw was publicly disclosed. Tracked as CVE-2026-19478 and rated 9.4 out of 10 on the CVSS scale, the code-injection bug lets an attacker send a specially crafted request through a GitLab GraphQL directive and, without ever logging in, modify or delete data in any publicly accessible project. Security firm watchTowr says it reproduced the exploit "within minutes" of disclosure, then watched real attackers hit its honeypot network roughly two days later.

What makes this one dangerous is the reach: watchTowr found that an unauthenticated attacker can delete entire repositories outright, forge merge records to make it look like a fix landed when it never did, and ban the project's own maintainers — all without an account, a password, or any user interaction. Researcher Jake Knott flagged the speed as the real story, noting that AI-assisted attackers are compressing the time from disclosure to exploitation from weeks down to days.

What this means for your business

• If you self-host GitLab Community or Enterprise Edition, patch this week to 19.2.4, 19.1.6, 19.0.8, or 18.11.11 — whichever release line you're on. GitLab.com's own hosted service has already been patched for you.
• If patching has to wait even a day or two, restrict unauthenticated access to the /api/graphql endpoint at your reverse proxy or firewall, or temporarily turn off public visibility on repositories that don't need to be browsable by anyone on the internet.
• Check your web server logs for requests containing @gl_introduced — that string is the fingerprint of this specific attack and a sign someone has already probed your instance.
• If any public repository shows merge commits, deleted branches, or maintainer removals you don't recognise, treat it as a live incident rather than a glitch: rotate any credentials that repository could reach and review the audit log before assuming it's nothing.

Self-hosted GitLab is common among small and mid-size development teams who want source control on their own infrastructure rather than a shared SaaS account — if that describes your setup, this is a same-week patch, not a someday item on the backlog.