GitLab ships an emergency fix for CVE-2026-19478: unauthenticated delete of public projects

GitLab shipped an ad hoc critical patch release on 17 August 2026, outside its normal schedule, for CVE-2026-19478, rated CVSS 9.4. Here is how GitLab describes the impact in its own advisory: the issue "under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive."

Read that sentence carefully, because it is narrower and stranger than most of the coverage suggests.

Patch to one of these four builds

• 18.11.11
• 19.0.8
• 19.1.6
• 19.2.4

Affected: every version from 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.

The trap is in that range. The affected window opens at 18.2, but the published fixes only cover the 18.11, 19.0, 19.1 and 19.2 branches. If you are running anything in 18.2 through 18.10, there is no in-branch patch for you. You cannot apply a point release and stay where you are. You have to upgrade to a supported release. Teams that have been sitting on an old 18.x because upgrades are disruptive are exactly the teams with the most work to do today.

GitLab.com and GitLab Dedicated are already running the patched version, and GitLab states those customers do not need to take action. This is a self-managed problem only.

It is not remote code execution

The vulnerability class is code injection, and a lot of write-ups slid from there to language about attackers running their own instructions on your server. GitLab did not say that, and the CVSS vector rules it out.

The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H.

The part to notice is C:L. Confidentiality impact is rated Low. Integrity and availability are both High. In plain terms, the 9.4 is driven by what an attacker can destroy and alter, not by what they can read or execute. This is a data-integrity and availability bug: unauthenticated modify and delete against public projects and user data. It is not a path to dumping your private repositories, and it is not a shell on the box.

That distinction changes your response. The realistic worst case is someone wiping or tampering with public projects, so your backup and restore position matters more than your egress monitoring here. Confirm you can restore a deleted project before you go hunting for exfiltration you are unlikely to find.

The same release also fixes CVE-2026-19650, a cross-site request forgery issue in the GraphQL multiplex query handler, rated CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L). Note the UI:R: that one needs a logged-in user to be lured into clicking, which is why it is the lesser of the two.

Both came in through HackerOne. GitLab credits hiimguardian for the critical GraphQL directive issue and kreep for the CSRF.

Exploitation status

No public proof-of-concept code had surfaced for either issue at the time of writing, and neither appears in CISA's Known Exploited Vulnerabilities catalog. That is a reason to move in an orderly way today, not a reason to wait. An unauthenticated, no-user-interaction bug on an internet-reachable endpoint is the profile that gets swept up in mass scanning once someone publishes a proof of concept, and GitLab breaking its own release schedule tells you how it rates the risk. GitLab's wording is that it "strongly recommends" affected installations upgrade "as soon as possible."

The takeaway

If you run self-managed GitLab with /api/graphql reachable from the internet, install 18.11.11, 19.0.8, 19.1.6 or 19.2.4 today. If you are on 18.2 through 18.10, schedule the jump to a supported branch now, because no patch is coming to yours. Everyone else, in this order: confirm your instance is not internet-facing, confirm your project backups restore, and then get to the CSRF fix on your normal cycle.