GitLab Ships an Emergency Patch for a Critical Unauthenticated Code Injection Flaw

GitLab pushed out an emergency patch release on August 17, 2026, just five days after a routine, scheduled update that carried no critical-rated fixes, to close a vulnerability that let unauthenticated attackers modify or delete public projects and user data over the network. GitLab rates the flaw Critical, with a CVSS score of 9.4 out of a maximum 10, according to SecurityWeek and GitLab’s own advisory.

The vulnerability, tracked as CVE-2026-19478, sits in how GitLab’s GraphQL API processes a directive: a modifier that changes how a GraphQL query or mutation runs. “GitLab has remediated an issue that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive,” the company said in its advisory. GitLab has not said which directive is involved or what conditions are required to trigger it.

What the severity score actually means here

The CVSS vector GitLab published for CVE-2026-19478, AV:N/AC:L/PR:N/UI:N, describes an attack that can be launched over the network, needs no special skill or timing, requires no account or credentials, and needs no action from a victim. The impact breakdown explains why GitLab treated it as urgent: high impact on integrity and availability, since an attacker can change or destroy data, but low impact on confidentiality, since the bug is not primarily a data-exposure hole. The Hacker News reports that no public proof-of-concept exploit code had surfaced as of August 18, 2026, and GitLab’s advisory does not claim the flaw has been exploited in the wild.

A second, lower-severity bug fixed in the same release

The same patch also closes CVE-2026-19650, a cross-site request forgery (CSRF) issue in the GraphQL multiplex query handler: the code path that lets a client bundle multiple GraphQL operations into a single request. GitLab rates it High, with a CVSS score of 7.1. Unlike the critical flaw, it requires a victim to interact with something first. GitLab’s advisory describes it as an issue that “could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling.” Both vulnerabilities were reported through GitLab’s HackerOne bug bounty program, credited to researchers using the handles hiimguardian and kreep.

Who needs to act

The fixes ship in GitLab Community Edition and Enterprise Edition versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11. Both bugs affect GitLab CE/EE in four separate ranges: 18.2 up to 18.11.11, 19.0 up to 19.0.8, 19.1 up to 19.1.6, and 19.2 up to 19.2.4. GitLab.com and GitLab Dedicated are already running the patched code, so hosted customers do not need to do anything. Self-managed installations are the ones exposed, and GitLab is telling every self-managed administrator to upgrade immediately.

One detail changes the remediation path for older deployments: the fix landed only in 18.11.11 and the three newer minor lines, not as a same-branch patch for every affected version. Installations still running the 18.2 through 18.10 branches, which fall inside the vulnerable range, do not get a patch on their own branch and have to upgrade forward to 18.11.11 or later to close the hole. GitLab says the update introduces no new database migrations and should not require downtime on multi-node deployments.

GitLab’s standard policy, stated on its release notes, is to keep the technical detail behind a patched vulnerability off its public issue tracker for 90 days after the fix ships, giving administrators a window to update before the specifics of an exploit become public. That clock started on August 17, which puts the detailed write-up for both CVE-2026-19478 and CVE-2026-19650 on track for mid-November.