{"id":2824,"date":"2026-08-18T03:56:58","date_gmt":"2026-08-18T10:56:58","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=2824"},"modified":"2026-08-18T03:57:00","modified_gmt":"2026-08-18T10:57:00","slug":"emerging-threat-cve-2026-19478-gitlab-unauthenticated-project-deletion-via-graphql-directive","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/emerging-threat-cve-2026-19478-gitlab-unauthenticated-project-deletion-via-graphql-directive\/","title":{"rendered":"Emerging Threat: (CVE-2026-19478) GitLab Unauthenticated Project Deletion via GraphQL Directive"},"content":{"rendered":"\n
\"\"
Sample of assets impacted by GitLab GraphQL Code Injection vulnerability, identified by the CyCognito Platform<\/em><\/figcaption><\/figure>\n\n\n\n

What is CVE-2026-19478?<\/h2>\n\n\n\n

CVE-2026-19478 is a code injection vulnerability in GitLab Community Edition and Enterprise Edition, caused by improper handling of a GraphQL directive in the application’s API layer. GitLab disclosed the issue and shipped fixes in an ad hoc critical patch release on August 17, 2026, outside its normal twice-monthly security schedule.<\/p>\n\n\n\n

The vulnerability carries a CVSS base score of 9.4 (Critical) as assigned by GitLab. Exploitation requires no authentication and no user interaction. An attacker who can reach the GraphQL endpoint over the network can, under conditions GitLab has not publicly detailed, modify or delete public projects and user data without holding a valid account on the instance.<\/p>\n\n\n\n

The practical impact is destructive rather than confidential. Source code, documentation, CI\/CD pipeline definitions, and infrastructure-as-code files held in public projects can be altered or removed. For organizations that treat a self-managed GitLab as the system of record for build definitions, tampering with pipeline configuration is a plausible path to downstream supply chain compromise.<\/p>\n\n\n\n

The same release addressed CVE-2026-19650, a cross-site request forgery weakness in GitLab’s GraphQL multiplex query handler, rated 7.1 (High). That issue allows GraphQL mutations to be executed via GET requests where request validation is incomplete, but it requires user interaction and is narrower in scope. At the time of writing there is no public proof-of-concept code for either issue, and neither appears in the CISA Known Exploited Vulnerabilities catalog.<\/p>\n\n\n\n

What assets are affected by CVE-2026-19478?<\/h2>\n\n\n\n

The vulnerability affects GitLab CE and EE 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. Only self-managed deployments require action. GitLab.com and GitLab Dedicated were patched by GitLab and need no customer intervention. The advisory applies regardless of deployment model, covering Omnibus packages, source installations, and Helm chart deployments alike.<\/p>\n\n\n\n

In practice, an affected asset is a self-hosted GitLab server published to the internet over HTTPS. It typically presents a login panel, a container registry, a Pages host, or a bare GraphQL endpoint at \/api\/graphql<\/code>. Instances are frequently reachable on non-standard ports as well as 443, and many are addressed by IP rather than by a hostname that maps cleanly to an owner.<\/p>\n\n\n\n

These systems tend to be internet-facing by design rather than by accident. Remote developers, external contractors, integration partners, CI runners, and inbound webhooks all need to reach them. That reachability makes them hard to pull behind a VPN once a workflow depends on it. They are also commonly stood up by engineering teams rather than central IT, which means they often sit outside the asset inventory that vulnerability management runs against.<\/p>\n\n\n\n

What does our data show about exposure patterns?<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Exposure across the externally reachable assets observed running GitLab is led by Industrials at 29.3%, with Information Technology contributing 19.3% and Communication Services 17.4%.<\/p>\n\n\n\n

The Industrials concentration reflects what that sector’s engineering organizations look like operationally. Commercial services, capital goods, and transport businesses run distributed technical teams across many sites, subsidiaries, and acquired entities, each with its own development toolchain and its own reasons to expose a repository server to outside collaborators. A self-hosted GitLab is a natural outcome of that structure, and long acquisition histories tend to leave several of them in place under different naming conventions and different owners.<\/p>\n\n\n\n

The cross-sector pattern points at the asset class rather than the industry. GitLab instances are developer infrastructure, procured and operated by engineering teams on their own schedule, published to the internet because a workflow requires it, and left running long after the project that justified them has ended. The gap that produces exposure here is one of ownership and inventory rather than one of patching discipline.<\/p>\n\n\n\n

Are fixes available?<\/h2>\n\n\n\n

Yes. GitLab released fixed versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 on August 17, 2026. GitLab states that the release introduces no new database migrations and that multi-node deployments should not require downtime when the documented zero-downtime upgrade process is followed. Default Omnibus behavior may briefly stop and restart services during reconfiguration.<\/p>\n\n\n\n

One gap deserves attention. The affected range starts at 18.2, but the published fixes do not cover the 18.2 through 18.10 branches. Organizations still running any of those releases have no direct patch and will need to upgrade to a supported branch instead.<\/p>\n\n\n\n

Defenders should confirm their exact running version and branch against GitLab’s advisory rather than assuming a recent-looking version string is safe. Instances managed by separate business units are the ones most likely to be missed, and the running version on those is frequently older than the central estimate.<\/p>\n\n\n\n

Are there any other recommended actions to take?<\/h2>\n\n\n\n

Alongside patching, defenders should:<\/p>\n\n\n\n