Summary
- GitLab issued an out-of-band fix for CVE-2026-19478, a critical GraphQL code-injection vulnerability rated 9.4.
- Affected self-managed versions can under certain conditions allow an unauthenticated remote attacker to modify or delete public projects and user data.
- GitLab.com and GitLab Dedicated were already patched, while fixed self-managed releases include 18.11.11, 19.0.8, 19.1.6, and 19.2.4.
GitLab has released an out-of-band security update for a critical GraphQL vulnerability that could allow an unauthenticated attacker to modify or delete public projects and user data on affected self-managed installations.
The flaw, tracked as CVE-2026-19478, has a CVSS score of 9.4 and affects GitLab Community Edition and Enterprise Edition. GitLab says the issue involves code injection through a GraphQL directive and can be exploited remotely under certain conditions without credentials or user interaction.
The affected ranges are all GitLab CE and EE versions 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. GitLab released fixed versions 18.11.11, 19.0.8, 19.1.6, and 19.2.4 on 17 August.
GitLab.com and GitLab Dedicated were already running patched versions when the advisory was issued, so the immediate exposure sits with customers operating their own GitLab infrastructure.
The company has not disclosed the precise GraphQL directive or the full conditions required for exploitation. Its advisory also does not report active exploitation in the wild. That limits the amount of technical detail available to attackers while administrators have time to deploy the update.
A second issue, CVE-2026-19650, was fixed in the same release. Rated high severity at 7.1, it concerns improper request validation in the GraphQL multiplex query handler and could under certain circumstances allow mutations to be executed through GET requests. Unlike the critical flaw, it requires user interaction.
Source-control platforms hold concentrated privilege
A vulnerability capable of changing or deleting public project data has consequences beyond ordinary application availability because GitLab sits inside software-development and deployment processes. Repositories can contain source code, pipeline definitions, infrastructure configuration, release artefacts, issue data, and integration settings that influence what reaches production.
The critical flaw is limited by GitLab’s description to public projects and user data, but unauthenticated write or deletion capability still creates integrity and availability risks. A successful attacker could interfere with project content or records without first compromising a user account, depending on the exact conditions present on the target installation.
Self-managed GitLab environments can also have very different exposure profiles. Some are reachable from the public internet to support distributed development, customers, or open-source collaboration, while others sit behind corporate access controls. The same software defect therefore produces different practical risk depending on how the instance and its projects are exposed.
The out-of-band nature of the release is notable. GitLab normally issues scheduled patch releases twice a month, but it also uses ad-hoc critical patches for high-severity problems that should not wait for the next routine cycle. That places the update outside the normal maintenance rhythm for organisations that plan GitLab changes around fixed windows.
GitLab says the patched versions introduce no new migrations and should not require downtime on multi-node deployments, although default Omnibus upgrade behaviour can still stop and restart services. That reduces some of the operational friction associated with an urgent update without removing the need to validate integrations and availability.
The vulnerability also illustrates the risk concentrated in developer platforms. Compromise of a source-control or DevOps system can create a path to software integrity, credentials, automation, and downstream environments even when the original weakness sits in an API layer rather than a build tool.
There is currently no public evidence that CVE-2026-19478 has been exploited. The combination of remote reachability, no authentication requirement, and high-integrity impact nevertheless explains why GitLab issued the fix outside its regular schedule and urged self-managed customers to move to a patched release.
