Critical GraphQL Flaw in GitLab Lets Attackers Delete Public Projects Without Authorization

GitLab has released an emergency security update for Community Edition and Enterprise Edition that fixes a critical vulnerability which, under certain conditions, lets a remote attacker with no account modify or delete public projects and user data.

The flaw has been assigned the identifier CVE-2026-19478 and a score of 9.4 on the CVSS scale. Judging by the published vector, the attack is carried out over the network and requires neither authentication nor any action on the victim's part. The cause is the handling of a certain GraphQL directive, though GitLab has named neither the directive itself nor the exact conditions required for exploitation.

Who needs to act

All versions from 18.2 up to the fixed releases 19.2.4, 19.1.6, 19.0.8 and 18.11.11 are affected. Only owners of self-managed installations need to update: the cloud platforms GitLab.com and GitLab Dedicated are already running the patched version, and their customers need do nothing.

Note separately that the 18.2 through 18.10 branches, which fall within the vulnerable range, did not receive fixes. The update itself, according to the company, adds no new migrations and requires no downtime, even on multi-node deployments.

The patch was released on August 17, 2026 — outside the usual schedule under which GitLab publishes updates twice a month. It came just five days after a scheduled release that contained no critical fixes.

The second flaw

The same release closes the vulnerability CVE-2026-19650, rated High (CVSS 7.1). This is a CSRF-type flaw in the handler for multiplexed GraphQL requests: because of improper request validation, an unauthenticated user could under certain conditions execute mutations via GET requests. Unlike the critical flaw, this one requires user interaction.

GitLab reports that no cases of exploitation of either vulnerability have been recorded, and no public exploit code was found as of August 18. As usual, the company will disclose the technical details in its tracker 90 days after the patch is released — that is, around mid-November 2026.

Recall that in July 2026 researchers published a working exploit for another GitLab vulnerability affecting self-managed servers, so administrators would do well to update without delay.

Source: The Hacker News