Attackers can modify or delete GitLab projects without logging In
- Evelyn Carter
- 10 hours ago
- 4 min read
GitLab released emergency patches on August 17, 2026, for CVE-2026-19478, a Critical vulnerability rated CVSS 9.4. Under certain conditions, an unauthenticated attacker can remotely modify or delete public projects and user data on self-managed GitLab CE/EE instances. GitLab recommends that affected organizations upgrade immediately.
Source code management platforms often contain software repositories, project histories, development workflows, and other business-critical data. As a result, a vulnerability that allows an external attacker to alter project information without first compromising an account creates a significant risk to data integrity and software development operations.
How serious is GitLab vulnerability CVE-2026-19478?
GitLab has classified CVE-2026-19478 as Critical, with a CVSS score of 9.4 out of 10. According to the vendor, an unauthenticated user can, under certain conditions, remotely modify or delete public projects and user data through a GraphQL directive.
These characteristics make the issue particularly relevant to GitLab instances exposed to the Internet. An attacker does not necessarily need to steal credentials, bypass MFA, or compromise an existing GitLab account before attempting exploitation.
The CVE Program currently classifies the weakness as Improper Control of Generation of Code, which aligns with GitLab's description of the issue as Code Injection.
However, the impact should not be overstated. GitLab has confirmed the ability to modify or delete public projects and user data, but its advisory does not state that CVE-2026-19478 enables arbitrary operating-system code execution or complete server takeover.
Which GitLab versions are affected?
The affected range includes multiple GitLab CE and EE releases beginning with version 18.2. On August 17, 2026, GitLab released four patched versions: 18.11.11, 19.0.8, 19.1.6, and 19.2.4. (GitLab)
GitLab branch | Affected versions | Patched version |
GitLab 18.x | 18.2 through versions before 18.11.11 | 18.11.11 |
GitLab 19.0 | Versions before 19.0.8 | 19.0.8 |
GitLab 19.1 | Versions before 19.1.6 | 19.1.6 |
GitLab 19.2 | Versions before 19.2.4 | 19.2.4 |
GitLab says GitLab.com and GitLab Dedicated are already running patched versions, meaning customers using those services do not need to take separate action for this update. Organizations running GitLab Self-Managed are the ones that need to verify their installed versions directly.
Only five days before this Critical patch release, GitLab had also issued versions 19.2.2, 19.1.4, and 19.0.6 to address 13 other security issues.
👉 IPSIP Vietnam covered that earlier update in GitLab releases emergency patches for 13 security vulnerabilities.
How could attackers exploit this GraphQL flaw?
GitLab has not yet disclosed the complete technical details of the vulnerability. The vendor has confirmed that CVE-2026-19478 involves a GraphQL directive, but it has not identified the directive or fully described the conditions required for successful exploitation.
GraphQL is an API technology that allows clients to request specific data or perform defined operations through a flexible interface. GitLab uses GraphQL to interact with multiple platform objects and functions.
Based on the information currently available, the following points can be confirmed:
exploitation can occur remotely over a network;
no authenticated GitLab account is required;
no existing privileges are required;
no user interaction is required;
public projects and user data may be affected;
What should organizations using GitLab Self-Managed do now?
Organizations should first determine whether GitLab Self-Managed is present in their environment and identify the exact version of every instance. If a system falls within the affected range, GitLab recommends upgrading to a patched release as soon as possible.
Inventory all GitLab Self-Managed instances, including production, staging, development, and legacy environments.
Confirm the exact GitLab version running on each instance.
Upgrade to 18.11.11, 19.0.8, 19.1.6, 19.2.4, or a newer supported release.
Identify GitLab and GraphQL endpoints that are directly exposed to the Internet.
Review records of public project modifications and deletions for unexplained activity.
Preserve audit logs, API logs, and reverse-proxy logs for potential investigation.
Verify backups of repositories and other critical GitLab data.
After patching, independently confirm the installed version and system status instead of relying only on the update process completing successfully.
For organizations operating large numbers of servers, websites, APIs, and Internet-facing services, the main challenge is often not knowing that a CVE exists, but knowing which internal assets are actually running vulnerable software.
👉 IPSIP's overview of information security assessment for businesses explains how version checks, server exposure, open services, configurations, accounts, and monitoring capabilities can be reviewed across an environment.
What does IPSIP Vietnam's security perspective suggest?
Git repositories and project management systems are often embedded directly into product development workflows. Unauthorized modification or deletion may affect software integrity, project continuity, and operational recovery. Organizations may also need significant investigation effort to distinguish legitimate changes from potentially malicious ones.
Critical patches should not be treated solely as an infrastructure team's problem. Organizations need coordinated Asset Inventory, Vulnerability Management, Patch Management, logging, and backup processes so they can respond quickly when a vendor releases an out-of-band security update.
For organizations in Vietnam operating GitLab Self-Managed, the immediate priority is to verify installed versions and deploy GitLab's patches. Log review and investigation of unusual project activity should follow. Longer term, Asset Inventory, Patch Management, Vulnerability Management, tested backups, and centralized monitoring are the controls that allow organizations to respond more effectively to similar Critical vulnerabilities.
References
Centre for Cybersecurity Belgium - Warning: Critical code injection vulnerability in GitLab CE/EE – available proof of concept – patch
The Hacker News - Critical GitLab GraphQL Flaw Could Let Unauthenticated Attackers Delete Public Projects
SecurityWeek - GitLab Patches Critical Code Injection Vulnerability
Comments