GitLab Fixes Critical GraphQL Flaw That Could Modify or Delete Projects

A Critical Vulnerability in Self-Managed Instances

GitLab released an out-of-band security update on August 17, 2026, just five days after its previous regular release. The update fixes two vulnerabilities in the Community Edition (CE) and Enterprise Edition (EE), with different levels of impact but both related to GraphQL usage.

The more serious issue is CVE-2026-19478, which GitLab rated Critical with a CVSS score of 9.4. Under certain conditions, a remote unauthenticated attacker could modify or delete public projects and user data through a GraphQL directive.

GitLab has not disclosed which directive is affected or the conditions required for successful exploitation. However, the CVSS vector indicates that the attack can be carried out over the network, without credentials or user interaction:

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

The score primarily reflects the impact on data integrity and availability. The confidentiality impact is considered more limited.

As of August 18, 2026, GitLab had not reported exploitation of the vulnerability. No public exploit code linked to CVE-2026-19478 was available on GitHub either. It is also unknown whether the flaw had been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog.

The Second Issue Affects GraphQL Mutations Over GET

The second flaw is CVE-2026-19650, rated High with a CVSS score of 7.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

The vulnerability is a Cross-Site Request Forgery (CSRF) weakness in the multiplex GraphQL query handler. Under specific conditions, insufficient request validation could have allowed an unauthenticated user to execute modification operations, known as mutations, through HTTP GET requests.

Unlike the critical flaw, this scenario requires user interaction. The victim would therefore have to perform an action that causes the attacker’s crafted request to be processed by the GitLab instance.

The issue does not automatically provide full access to the server. However, it could enable unauthorized operations that modify data, potentially affecting projects, configurations, and resources managed by the platform. GitLab has not published enough information to reconstruct the attack flow precisely.

Vulnerable and Fixed Versions

Fixes were released in the following versions:

• 19.2.4
• 19.1.6
• 19.0.8
• 18.11.11

The following versions are vulnerable:

• all 18.2 versions before 18.11.11;
• 19.0 versions before 19.0.8;
• 19.1 versions before 19.1.6;
• 19.2 versions before 19.2.4.

Operators using the 18.2 through 18.10 branches will not receive an extended fix for those branches and should plan an upgrade to a supported, patched version. The exact installed version can be checked on the instance administration page or through the management tools for the deployed package.

The issue affects self-managed installations only. GitLab.com and GitLab Dedicated are already running fixed versions, so customers of these services do not need to apply manual updates.

The update introduces no new migrations and should not require downtime in multi-node installations. Standard operational checks are still recommended, particularly in environments with distributed nodes, proxies, or GraphQL components exposed through custom infrastructure.

What Administrators Should Do

GitLab’s recommended mitigation is to upgrade to one of the four fixed versions. No equivalent alternatives have been provided, such as temporarily disabling a specific GraphQL directive or deploying a WAF rule sufficient to block both issues.

Administrators should therefore:

1. verify the version of the self-managed instance;
2. upgrade to 19.2.4, 19.1.6, 19.0.8, or 18.11.11;
3. review application and access logs for anomalous GraphQL requests;
4. investigate unexpected changes to public projects, repositories, issues, configurations, and user data;
5. check for unusual GET requests associated with GraphQL operations that modify data.

The security brief does not provide specific indicators of compromise, campaign names, or known network patterns. Logs may therefore not distinguish a successful attack from legitimate activity without correlating URLs, identities, timestamps, and the resulting changes.

Organizations unable to upgrade immediately should reduce the instance’s exposure by limiting external access according to their operational requirements. This is not a substitute for patching and does not guarantee protection if the instance must remain reachable from untrusted networks.

Technical Disclosure Expected in the Coming Months

GitLab stated that it will publish vulnerability details on its issue tracker 90 days after the fixes are released. Technical disclosure for these two issues is therefore expected around mid-November 2026.

This timeline is not entirely consistent with a previous statement issued on June 10, 2026, which cited a 30-day window. Until the details are published, the GraphQL directive involved in the critical flaw, the complete exploitation prerequisites, and the methods for bypassing GET request validation remain unknown.

The incident follows a July 2026 report on a separate GitLab vulnerability. In that case, researchers published working exploit code targeting self-managed servers. The company did not immediately respond to a request for comment on this new update.

For administrators, the priority remains unchanged: identify instances within the vulnerable version ranges and move them promptly to a fixed release rather than waiting for the future technical disclosure.