NEWS

Critical GitLab GraphQL Flaw Lets Unauthenticated Attackers Delete Public Projects

CVE-2026-19478 (CVSS 9.4) lets unauthenticated attackers delete public GitLab projects via GraphQL. Self-managed CE/EE must patch to 19.2.4 immediately.

Dylan H.

News Desk

August 17, 2026
4 min read
Critical GitLab GraphQL Flaw Lets Unauthenticated Attackers Delete Public Projects

Critical Out-of-Band GitLab Patch — Immediate Action Required

GitLab has issued a critical out-of-band security release patching CVE-2026-19478, a critical vulnerability in the platform's GraphQL API that allows an unauthenticated attacker to delete or modify public projects remotely — with no credentials, no privileges, and no user interaction required.

The vulnerability carries a CVSS score of 9.4 and affects both GitLab Community Edition (CE) and Enterprise Edition (EE). GitLab.com and GitLab Dedicated are already running the patched versions; self-managed instance administrators must upgrade immediately.


Vulnerability Details

FieldDetails
CVECVE-2026-19478
CVSS Score9.4 (Critical)
CVSS VectorAV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
ComponentGraphQL API — directive handling
Authentication RequiredNone
User InteractionNone
Discoveryhiimguardian via HackerOne bug bounty

Affected Versions

All GitLab CE/EE versions from 18.2 up to (but not including):

BranchFixed Version
19.2.x19.2.4
19.1.x19.1.6
19.0.x19.0.8
18.x18.11.11

Technical Analysis

The GraphQL Directive Flaw

The vulnerability resides in GitLab's GraphQL directive handling. Under certain conditions, an unauthenticated attacker can send crafted GraphQL requests that remotely modify or delete public projects and user data. The flaw bypasses GitLab's access control layer at the GraphQL API level.

# Simplified representation of the attack surface
mutation {
  destroyProject(input: {
    id: "gid://gitlab/Project/TARGET"
  }) {
    errors
  }
}

Full technical details — including specific mutation names and proof-of-concept payloads — are under GitLab's standard 30-day post-patch embargo. GitLab publishes full issue details on their tracker 30 days after the patching release to allow administrators time to upgrade.

Secondary Vulnerability (Same Release)

A second related flaw was patched simultaneously — CVSS 7.1, credited to researcher kreep: improper request validation in GraphQL multiplex query handling allowed unauthenticated users to execute GraphQL mutations via HTTP GET requests, bypassing the conventional POST-only constraint that GraphQL implementations rely on as an implicit CSRF guard.

Context: Broader GraphQL Audit

On August 12, 2026, GitLab's 19.2.2 release patched a separate unauthenticated GraphQL API DoS via malformed JSON parsing (CVE-2026-3988). The back-to-back GraphQL patches indicate an active security audit of the GraphQL attack surface is underway across the GitLab codebase.


Exploitation Status

No known active exploitation has been reported as of the patch release date. However, given:

  • Zero authentication requirement
  • CVSS 9.4 severity
  • Fully network-exploitable
  • Affects all GitLab versions since 18.2

Exploitation risk for unpatched self-managed instances is considered high. Public proof-of-concept code is expected to emerge within the 30-day embargo window, dramatically increasing exploitation likelihood.


Who Is Affected

Not Affected (Already Patched)

  • GitLab.com (SaaS) — running patched versions
  • GitLab Dedicated — running patched versions

Must Upgrade Immediately

  • Self-managed GitLab CE/EE running any affected version (all 18.2+ through pre-fix)

Upgrade Instructions

# For Omnibus/package installations
sudo apt update && sudo apt install gitlab-ee
# or
sudo yum update gitlab-ee
 
# Verify version after upgrade
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A5
 
# Note: This update includes database migrations
# Single-node deployments should plan for brief downtime

For Docker installations: Pull the updated image tag (19.2.4, 19.1.6, 19.0.8, or 18.11.11 depending on your branch).


Defensive Measures for Immediate Application

If immediate upgrade is not possible:

  1. Restrict public project visibility — temporarily set all public projects to internal while patching
  2. Enable GraphQL rate limiting — reduces attack throughput
  3. Deploy a WAF rule blocking unauthenticated GraphQL mutation requests
  4. Monitor GraphQL API access logs for anomalous destroy/delete mutation activity
  5. Restrict management interface access to trusted IP ranges

Sources