Vulnerabilities

Attackers Are Hitting GitLab’s Critical GraphQL Bug Without Logging In

September 3, 2026

4 mins

The Mess: A critical GitLab vulnerability, CVE-2026-19478, allows unauthenticated attackers to remotely modify or delete public projects and user data through a vulnerable GraphQL directive. The flaw has a CVSS score of 9.4, and exploitation attempts appeared shortly after GitLab released the patches.
The Damage: An attacker does not need a GitLab account to interfere with vulnerable public projects. For organizations using GitLab as the center of their CI/CD workflows, unauthorized repository changes can become a much bigger problem than a deleted project.
The Fix: Update self-managed GitLab CE/EE immediately to 18.11.11, 19.0.8, 19.1.6 or 19.2.4, depending on your release branch. GitLab.com and GitLab Dedicated are already patched.

GitLab’s GraphQL API just became a very bad place to leave unpatched.

CVE-2026-19478 is a critical code injection vulnerability affecting self-managed GitLab Community Edition and Enterprise Edition installations.

The CVSS score is 9.4.

More importantly, the attacker does not need to authenticate.

According to GitLab, the vulnerability can allow an unauthenticated attacker to remotely modify or delete public projects and user data through a vulnerable GraphQL directive.

No GitLab account.

No stolen password.

No social engineering.

Just a vulnerable instance and a reachable public object.

GitLab released an out-of-band critical security update on August 17 to address the issue.

The affected versions include GitLab CE/EE releases from:

18.2 before 18.11.11
19.0 before 19.0.8
19.1 before 19.1.6
19.2 before 19.2.4

The fixed versions are:

18.11.11
19.0.8
19.1.6
19.2.4

GitLab.com and GitLab Dedicated customers do not need to take action because those environments are already running patched versions.

The problem is with self-managed GitLab.

And that distinction matters.

GitLab is not just another application sitting on a server.

For many organizations, it sits directly in the software supply chain.

Source code.

CI/CD pipelines.

Build processes.

Deployment automation.

Merge requests.

Package registries.

Infrastructure configuration.

A compromise involving unauthorized repository modification can therefore have consequences far beyond the GitLab interface itself.

Delete a project and everyone notices.

Modify something quietly and the story gets more interesting.

That is why an unauthenticated vulnerability affecting public project data deserves attention even if the immediate advisory focuses on modification and deletion.

A source-code platform is often trusted by everything downstream from it.

Developers trust repositories.

CI systems trust repositories.

Automated deployment systems trust repositories.

Production infrastructure may eventually trust artifacts built from those repositories.

That makes integrity the real problem.

Security researchers reported that exploitation activity appeared rapidly after the vulnerability became public. Technical analysis and proof-of-concept material also followed quickly, reducing the time defenders had between disclosure and potential attacks.

That is now the normal vulnerability lifecycle.

Patch released.

Researchers inspect the changes.

The vulnerable code becomes easier to identify.

PoCs appear.

Internet-facing instances start receiving requests.

Then someone discovers that their GitLab server was not as invisible as they thought.

Organizations should not assume that a GitLab instance is safe simply because it is used internally.

Self-managed installations frequently expose services to the internet for developer access, integrations, runners, APIs and automated workflows.

Public projects make the situation particularly relevant because the vulnerability can target accessible unauthenticated objects.

Administrators should therefore update immediately and review logs for suspicious GraphQL activity.

Unexpected mutations involving public projects deserve particular attention.

So do unexplained repository changes, deleted objects and unusual API requests.

The second vulnerability fixed in the same GitLab release, CVE-2026-19650, is a separate high-severity CSRF issue affecting the GraphQL multiplex query handler.

But CVE-2026-19478 is the one demanding immediate attention.

It is critical.

Remote.

Unauthenticated.

And attackers did not wait around after disclosure.

Bugstoday’s take: GitLab is part of the software supply chain, which means a vulnerability allowing unauthenticated modification of projects should make more people nervous than a typical web application bug. When attackers can touch the place where your code lives, the question is no longer just whether a project can be deleted. The more interesting question is what happens if somebody changes something nobody notices.

Today’s Bugs. Tomorrow’s Breaches.