External risk intelligence

GitLab GraphQL Vulnerability Allows Unauthenticated Project Data Modification

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-19478

GitLab instances are frequently deployed as public-facing web applications to facilitate collaborative software development. Because the vulnerability affects a GraphQL endpoint accessible to unauthenticated users on these internet-exposed platforms, it is considered very likely to be reachable from the public internet in normal deployments.

Code Injection

Halo Surface Signal: 5 out of 5 — more likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in GitLab that could permit an unauthenticated user to remotely alter or erase public project and user data through a specific GraphQL directive. This issue affects certain versions of GitLab CE/EE, and its potential for remote, unauthenticated access to modify or delete data is a significant concern. The primary leadership concern is to confirm whether the organization's GitLab instance is exposed and affected, as this could have substantial implications for data integrity and availability.

Unauthenticated users could alter or delete public GitLab data.
Confirms if our GitLab instance is affected and exposed.
Understand exposure and data integrity risks.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker could exploit this vulnerability by sending specially crafted requests to a GitLab instance's GraphQL endpoint. This exposure allows an attacker to remotely alter or remove data from public projects.

Unauthenticated network access required.
Triggered via GraphQL directive.
Allows data modification or deletion.

Live Threat

Current exploitation, exposure, and threat context

An unauthenticated user could remotely modify or delete public projects and user data when interacting with the affected GitLab GraphQL API.

Public project data and user information.
Via a GraphQL directive.
Unauthorized data modification or deletion.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-World Ownership

Application owners and platform teams are most likely responsible for addressing this vulnerability in GitLab. The first practical move is to identify all GitLab instances, confirm their exposure and business criticality, and then engage the accountable owners to plan remediation during the next maintenance window.

Application and Platform teams should own the issue.
Verify GitLab instance reachability and criticality.
Plan remediation during the next maintenance window.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is GitLab CE/EE?

GitLab CE (Community Edition) and EE (Enterprise Edition) are integrated software development platforms. They provide tools for source code management, continuous integration, and project tracking. Organizations use these platforms to host code repositories and manage collaborative workflows, often making project data accessible to internal teams or the public.

What does CWE-94 mean in the context of CVE-2026-19478?

CWE-94 refers to Improper Control of Generation of Code, often called Code Injection. In this CVE, it means the application incorrectly processes instructions from a GraphQL directive. Instead of simply querying data, the system inadvertently executes commands that allow unauthorized modification or deletion of project and user information.

How does an attacker trigger this GitLab vulnerability?

An attacker triggers this issue by sending a specially crafted request to the GraphQL endpoint. The vulnerability relies on the application misinterpreting a specific directive within that request. It is important to note that this requires no authentication, but the actions are limited to public projects; private or internal projects do not trigger this specific path.

Is my GitLab instance at risk according to Halo Surface Signal?

Halo Surface Signal indicates a high likelihood of risk because GitLab instances are commonly deployed as public-facing web applications. Since this vulnerability is reachable via the internet without requiring an account, any instance exposed to the public network is considered a prime target for remote exploitation.

What steps should I take if I run GitLab?

First, identify all GitLab instances within your environment and verify which versions are currently running. If you are on an affected version, engage your platform or application team immediately to plan for an update. Prioritize these updates to protect your public projects from unauthorized data modification or deletion.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.