A critical vulnerability CVE-2026-19478 with a CVSS 9.4 score has been discovered in GitLab Community Edition and Enterprise Edition. It allows an unauthenticated attacker to modify and delete publicly accessible GitLab projects without any credentials or user interaction. Patches have already been released, and organizations with self-hosted GitLab instances exposed to the internet should update immediately. The company watchTowr reports signs of exploitation of the vulnerability, although this information has not yet been confirmed by independent sources.
Technical details of the vulnerability
CVE-2026-19478 is classified as a code injection vulnerability. According to reports, exploitation is possible via a GraphQL directive — a mechanism GitLab uses to process API requests. The key risk is that the attack requires neither authentication nor any specific configuration of the target instance.
Affected versions of GitLab CE and EE:
- 18.2 — up to 18.11.11
- 19.0 — up to 19.0.8
- 19.1 — up to 19.1.6
- 19.2 — up to 19.2.4
Fixes are available in versions 18.11.11, 19.0.8, 19.1.6 and 19.2.4.
According to researchers from watchTowr, the impact of exploitation goes beyond simple modification of public projects. In their post, they suggest that an attacker may be able to:
- Delete entire repositories
- Forge merge records, creating the appearance of applied fixes that never actually occurred
- Block project maintainers
It is important to note that these broader impact scenarios are based on a single research source and have not yet been confirmed by an official GitLab advisory or other independent organizations.
Exploitation status
watchTowr has stated that they were able to reproduce the vulnerability within minutes of public disclosure and observed signs of exploitation in their honeypot network. However, at the time of writing, the vulnerability has not been added to the CISA KEV catalog, and claims of active exploitation have not been confirmed by the vendor or other authoritative sources. The exploitation status should be regarded as unconfirmed — this does not reduce the criticality of the vulnerability itself, but it does affect the assessment of the immediate threat.
watchTowr researcher Jake Knott linked the speed of the transition from disclosure to exploitation to attackers’ use of artificial intelligence tools, which in his view compresses the response window. Regardless of whether the role of AI in this particular case is confirmed, the trend toward shorter intervals between disclosure and the first attacks has been an objective reality in recent years.
Impact assessment
The highest risk is to organizations running self-hosted GitLab instances exposed to the internet with public repositories. Given that GitLab is widely used to store source code, manage CI/CD pipelines, and coordinate development, compromise of repositories can lead to:
- Insertion of malicious code into the software supply chain
- Irreversible data loss if repositories are deleted
- Undermining trust in change history through forged merge records
- Disruption of workflows if maintainers are blocked
The merge record forgery scenario is particularly dangerous: in theory, an attacker could create the appearance that a vulnerability in a project has already been fixed while the malicious code remains in place.
Response recommendations
The top priority is immediate updating to one of the fixed versions: 18.11.11, 19.0.8, 19.1.6 or 19.2.4.
If an immediate update is not possible, the following temporary measures are recommended:
- Restrict unauthenticated access to the
/api/graphqlendpoint at the web server or reverse proxy level - Completely disable public access to repositories until the patch is applied
- Analyze web server logs for requests containing the string
@gl_introduced— according to researchers, this may indicate exploitation attempts or reconnaissance
Organizations that detect suspicious requests to the GraphQL API should perform an integrity audit of the affected repositories: check commit history, merge records, and the status of maintainer accounts.
Given the CVSS 9.4 score and the lack of any authentication requirement for exploitation, updating self-hosted GitLab instances to versions 18.11.11, 19.0.8, 19.1.6 or 19.2.4 should be carried out outside the regular patch cycle — within hours, not days. Organizations that cannot update immediately should at a minimum block unauthenticated access to /api/graphql and review logs for reconnaissance indicators.
