CVE-2026-19478

This vulnerability is like a “back door” in GitLab that lets someone on the internet tamper with public project files and user information, without having to log in. Think of it as letting an outsider rewrite pages in your shared notebook and erase entries—potentially breaking your work and harming trust in your data.

This matters if you run GitLab CE/EE and your instance has public projects or user data that can be accessed over the network (including being reachable with the default setup). The risk is only relevant if your GitLab version is vulnerable and the system is reachable from the internet—no login and no human interaction are required for the attacker.

This is urgent because exploitation has been reported in the real world shortly after disclosure, and the flaw allows unauthenticated remote modification or deletion of data. Since it is reachable in default configuration and does not require login, waiting increases the chance your GitLab could be targeted and damaged.

1. Confirm exposure

• Identify how your GitLab is reachable: is it accessible from the internet (public URL, load balancer, reverse proxy, or open ports)?
• Confirm whether you use public projects or otherwise allow access to project files and user-related information that could be impacted as described.
• Check your running GitLab CE/EE version.

2. Determine whether you’re vulnerable

• This issue affects vulnerable versions prior to the stated fixes:
  • All 18.2 releases before 18.11.11
  • All 19.0 releases before 19.0.8
  • All 19.1 releases before 19.1.6
  • All 19.2 releases before 19.2.4

3. Upgrade to the fixed version

• Upgrade to at least one of the fixed versions (depending on your branch/version line):
  • 18.11.11 (or above)
  • 19.0.8 (or above)
  • 19.1.6 (or above)
  • 19.2.4 (or above)

4. Post-upgrade verification (important)

• Review public project file integrity: compare key repositories/files against your expected state.
• Verify user data that could be impacted still matches expectations (e.g., ensure no records were unexpectedly modified or deleted).
• Look for unexpected changes around the time of the reported exploitation window (starting around the August 17, 2026 disclosure and onward).

5. If you cannot upgrade immediately

• Treat this as an emergency containment problem: restrict network access to GitLab as much as possible (e.g., IP allowlists/VPN access) until you can upgrade.
• Ensure the instance is not reachable publicly if you cannot patch right away.

6. What to monitor going forward

• Monitor logs for suspicious GraphQL-related requests and unexpected write/delete activity in projects and user data.
• Recheck version periodically to ensure no nodes are left on vulnerable releases after maintenance.

Severity is critical (CVSS 9.4). The weakness is CWE-94 (Improper Control of Generation of Code), but in this case it manifests as a remote modification/deletion of data outcome. The attack is network-based and requires no authentication and no user interaction. Detection/exploit details are not provided beyond a detection template.

Exploitation status: exploitation has been reported (WatchTowr observed in-the-wild exploitation attempts shortly after disclosure). KEV is not listed in CISA KEV.

Attack vector/mechanism: an unauthenticated attacker can exploit specific GraphQL directive handling in GitLab to remotely alter or delete public project files and user information.

Affected range: GitLab CE/EE 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.

Fix: upgrade to GitLab 18.11.11, 19.0.8, 19.1.6, or 19.2.4 or later.

Exploit maturity: active, real-world exploitation attempts have been observed.