Last updated: August 19, 2026 at 1:47 AM UTC
All 741 Vulnerability 286 Breach 129 Threat 319 Defense 7
Tag: self-managed (2 articles)Clear

Critical GitLab flaw lets unauthenticated attackers delete public projects and data

GitLab shipped an out-of-band critical patch for a flaw that lets an unauthenticated attacker remotely modify or delete public projects and user data through a GraphQL directive. Tracked as CVE-2026-19478 and scored 9.4, it affects self-managed Community and Enterprise installations; GitLab.com and Dedicated are already fixed. The company released it outside its normal twice-monthly schedule, and the fixed versions are 19.2.4, 19.1.6, 19.0.8, and 18.11.11, with the 18.2 through 18.10 branches left in the affected range and needing an upgrade. A second, lower-severity GraphQL flaw involving cross-site request forgery was fixed in the same release. GitLab reports no known exploitation yet.

Check
Upgrade self-managed GitLab to a fixed release immediately, and if you run a version between 18.2 and 18.10, plan an upgrade since those branches did not receive a backported fix.
Affected
Organizations running self-managed GitLab Community or Enterprise Edition (CVE-2026-19478); an unauthenticated attacker can remotely modify or delete public projects and user data through a GraphQL directive.
Fix
Apply the out-of-band patch now, prioritize internet-reachable instances, review logs for unexpected GraphQL activity and project or user changes, and restore any affected projects from backups if tampering is found.

Public exploit runs commands as git on unpatched self-managed GitLab servers

A researcher at depthfirst published a working exploit on July 24 for a GitLab flaw patched on June 10, running commands as the git user on any self-managed 18.11.3 server that has not updated. Any authenticated user who can push to a project can trigger it: the attacker commits a crafted Jupyter notebook and opens its commit diff to leak a heap pointer, repeats until an automated probe locates libraries in memory, then fires the payload with two more notebooks. No administrator rights, runner access, or victim interaction are needed. The bug sits in the notebook renderer, which passes repository-controlled data to a parser inside a long-lived worker.

Check
Move self-managed GitLab to a supported release containing the June fix, and for Helm or Operator deployments verify the GitLab version inside the Webservice image rather than only the chart version.
Affected
Self-managed GitLab servers on 18.11.3 or other unpatched builds; any authenticated user able to push a project can run commands as the git service account, with public exploit code now available.
Fix
Upgrade to a fixed release, since no workaround is offered, and note GitLab did not classify the fix as a security issue, so track upstream library bumps rather than security advisories alone.