CVE-2026-19478 in GitLab
Summary
by MITRE • 08/17/2026
GitLab has remediated an issue in GitLab CE/EE affecting all 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 that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/17/2026
GitLab has addressed a critical security vulnerability affecting multiple versions of its Community Edition (CE) and Enterprise Edition (EE) platforms, specifically impacting releases from 18.2 up to but not including 18.11.11, as well as versions 19.0 prior to 19.0.8, 19.1 prior to 19.1.6, and 19.2 prior to 19.2.4. This flaw represents a significant breach in access control mechanisms within the GraphQL API layer of the GitLab application. The vulnerability allows an unauthenticated user, meaning no valid login credentials or session tokens are required, to execute operations that should be strictly restricted to authorized administrators or project owners. Specifically, the issue stems from improper validation of directives used in GraphQL queries, which enables attackers to bypass standard authentication checks and interact directly with backend data structures associated with public projects and user profiles.
The technical root cause lies in how GitLab processes specific GraphQL directives during query execution. In a properly secured system, any operation that modifies or deletes sensitive data must be preceded by rigorous verification of the requester's permissions against the target resource. However, due to this flaw, certain directive-based queries were processed without enforcing these necessary access control checks. This oversight creates a pathway for remote code-like manipulation where an attacker can craft malicious GraphQL requests targeting public repositories and user information fields. Because the affected endpoints are exposed via the API, which is often accessible over standard HTTP or HTTPS ports, the attack vector is fully remote and does not require physical proximity or network-level access beyond what is typically available to any internet-connected client.
The operational impact of this vulnerability is severe due to its potential for data integrity compromise and unauthorized modification of public assets. An attacker can remotely delete public projects, effectively causing denial of service by removing accessible codebases and documentation from the platform without authorization. Furthermore, the ability to modify user data poses a risk to privacy and account security, potentially allowing attackers to alter profile information or other metadata associated with users whose data is exposed through these endpoints. This level of access undermines the trust model of the GitLab instance, as public projects are generally assumed to be read-only for unauthenticated visitors unless explicitly configured otherwise by administrators. The lack of authentication requirement makes this vulnerability particularly dangerous in automated attack scenarios where bots can scan and exploit instances at scale without needing to first compromise user credentials through phishing or brute-force attacks.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as the system failed to restrict access to resources based on proper authorization checks. It also relates to CWE-915 Improper Modification of Functionality with Incorrectly Specified Input, given that the GraphQL directives were manipulated to perform unintended state changes. In terms of the MITRE ATT&CK framework, this exploit maps to T1078 Valid Accounts if it involved compromised credentials, but since it is unauthenticated, it falls under broader categories of exploiting API flaws and potentially T1496 Resource Hijacking or data manipulation techniques that do not require initial access. The vulnerability highlights the risks associated with exposing complex query languages like GraphQL without strict schema-level enforcement of authorization policies for all mutation operations.
To mitigate this risk, organizations running affected versions must immediately upgrade to the patched releases: 18.11.11 and later for the 18.11 branch, 19.0.8 and later for the 19.0 branch, 19.1.6 and later for the 19.1 branch, or 19.2.4 and later for the 19.2 branch. Until upgrades are performed, administrators should consider implementing web application firewall rules that inspect GraphQL traffic for suspicious directive patterns known to exploit this flaw. Additionally, reviewing access logs for unusual spikes in unauthenticated mutation requests can help identify potential active exploitation attempts. It is also advisable to audit public project settings and user data exposure configurations to ensure that no sensitive information was altered during the window of vulnerability. Regular patching cycles and monitoring of vendor security advisories are essential practices to maintain the integrity and availability of GitLab instances in production environments.