GitLab has issued emergency security patches to fix a critical vulnerability that could have allowed attackers with no credentials to remotely erase or alter public projects and user information. The company released the fixes on August 17, 2026, five days outside its normal twice-monthly update cycle. The flaw affects both the Community Edition and Enterprise Edition of GitLab's software, though only organizations running their own installations need to take action.
The vulnerability, designated CVE-2026-19478, carries a CVSS severity rating of 9.4 out of 10, earning GitLab's own Critical classification. Patched versions are now available as 19.2.4, 19.1.6, 19.0.8, and 18.11.11. All versions from 18.2 through 18.11.10 are vulnerable, as are versions 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. GitLab hasn't released fixes for the 18.2 through 18.10 branches, which fall inside the affected range. The CVSS vector shows the weakness can be exploited over a network by someone holding no credentials and without requiring any victim action. The company also fixed a second issue, CVE-2026-19650, rated High with a CVSS score of 7.1, involving a cross-site request forgery weakness in the GraphQL multiplex query handler that does require user interaction.
According to the advisory, "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 its hosted services, GitLab.com and GitLab Dedicated, are already running the patched versions and their customers don't need to act. GitLab hasn't disclosed what the GraphQL directive involved is or what conditions are required for someone to exploit the flaw. The advisory notes no exploitation of either vulnerability has been observed, and no public exploit code had appeared on GitHub as of August 18, 2026.
The critical flaw sits in GitLab's GraphQL interface, a technology that lets applications query and change data through structured requests. Because the vulnerability needs no authentication and works over a network, an attacker could theoretically target any self-managed GitLab installation running the affected versions without needing to trick a user or obtain login credentials first. The company's decision to release patches outside its scheduled update window—which normally falls on the second and fourth Wednesdays of each month—signals the severity it assigned to the risk. The last routine patch release arrived just five days earlier and carried no critical-rated issues.
GitLab said the update introduces no new database migrations and shouldn't require downtime on multi-node deployments. The company will make the technical details of both vulnerabilities public on its issue tracker 90 days after the patch release, putting full disclosure around mid-November 2026. That's an extension from the 30-day window the company used for its June 10, 2026 patch release. The disclosure comes one month after researchers published working exploit code for a separate GitLab flaw affecting self-managed servers in July 2026. Organizations that run their own GitLab instances should prioritize installing the patches, particularly since the vulnerability requires no user action to exploit and targets the widely used GraphQL interface that many development workflows depend on. The company's silence on exploitation attempts and the absence of public exploit code provide a narrow window for administrators to patch before the risk escalates. For development teams that treat GitLab as the central repository for code and project data, the potential for an unauthenticated attacker to delete or modify that work represents an existential threat to operational continuity.