GitLab CVE-2026-19478 Actively Exploited Days After Disclosure

GitLab vulnerability CVE-2026-19478 was observed being exploited in the wild just days after its public disclosure. The activity was detected on August 21, 2026, by watchTowr, which identified attacks against its honeypot network.

The company said it reproduced the issue within minutes of its disclosure. The flaw allows a remote, unauthenticated attacker to tamper with publicly accessible GitLab projects without credentials or user interaction.

Code Injection Through GraphQL

The vulnerability affects a GraphQL directive and is classified as code injection, under CWE-94. Under certain conditions, a specially crafted request can allow an attacker to modify or delete projects and associated data.

The description published by NVD confirms that the attack can be conducted remotely against public projects and user data. No privileges are required, and the attack complexity is considered low.

The CVSS v3 score is 9.4:

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

Confidentiality is rated as having a low impact, while integrity and availability can be severely compromised. In practice, an attacker could alter content and configurations or make critical project components unavailable.

Deleted Repositories and Forged Merges

According to watchTowr, the impact extends beyond modifying individual data. A successful exploit may allow an attacker to:

• delete entire repositories;
• alter project data;
• forge merge records;
• remove or block maintainers;
• make a fix appear to have been merged when it was never actually applied.

Forged merge records are particularly concerning because they can undermine trust in development workflows. A project may show a change as already merged even though the corrected code was never actually applied or verified.

The issue primarily affects Internet-exposed instances with public repositories and externally reachable GraphQL functionality. No specific threat group has been linked to the observed attacks.

Affected GitLab Versions

Both GitLab Community Edition (CE) and Enterprise Edition (EE) are affected.

The vulnerable versions are:

• 18.2 releases earlier than 18.11.11;
• 19.0 releases earlier than 19.0.8;
• 19.1 releases earlier than 19.1.6;
• 19.2 releases earlier than 19.2.4.

GitLab fixed the flaw in:

• 18.11.11;
• 19.0.8;
• 19.1.6;
• 19.2.4.

Administrators should identify the branch in use and apply the corresponding release rather than checking only the major version number. An instance running a release prior to the fixed version remains vulnerable.

Rapid Exploitation Narrows the Window for Response

The timeline observed by watchTowr shows only a very short interval between disclosure and exploitation. Jake Knott, the company’s principal security researcher, linked this speed to tools and processes enabled by artificial intelligence.

This is an observation about the acceleration of offensive activity, not an attribution to a specific threat actor. The operational takeaway is clear: once technical details are published, the time available to update systems may be extremely limited.

Based on the available information, the vulnerability has not been listed in the CISA KEV catalog. No related CISA deadline is therefore available. Its absence from the catalog does not reduce the urgency of remediation: in-the-wild exploitation was directly observed by watchTowr.

Update GitLab and Review the Logs

The primary mitigation is to update CE or EE instances to the appropriate fixed version: 18.11.11, 19.0.8, 19.1.6, or 19.2.4, depending on the installed branch.

If an immediate update is not possible, GitLab recommends implementing one of the following mitigations:

• restrict unauthenticated access to the /api/graphql endpoint;
• completely disable access to public repositories.

These measures reduce the exposed attack surface but do not replace the software fix. After updating, organizations should ensure that temporary restrictions are removed only once the risk has been properly addressed.

Organizations that have not yet applied the patches should review web logs for requests containing:

@gl_introduced

The review should also cover indicators of scanning, probing, and exploitation attempts. Recent changes to repositories, project data, merge records, and maintainer permissions should be compared against expected activity.

Unauthorized changes, missing repositories, removed maintainers, or unexpected merges require an investigation of the accounts involved, application logs, and backups. If suspicious activity is found, restoring the repository alone is not enough: metadata, permissions, and the full operation history must also be checked.