A critical GitLab flaw can allow project deletion without login

On 17 August 2026 GitLab shipped an out of band patch release, with versions 19.2.4, 19.1.6, 19.0.8 and 18.11.11 for both Community Edition and Enterprise Edition. The release fixes two vulnerabilities, both in GitLab's GraphQL layer. The more serious one, CVE-2026-19478, carries a CVSS score of 9.4 and a severity of critical. GitLab asks every self managed installation to upgrade immediately. GitLab.com and GitLab Dedicated already run the fixed version.

What happens technically

GraphQL is a query language where the client sends a single request describing exactly which data it wants, and where that request may carry directives, meaning instructions that change how the query is processed. Both vulnerabilities live in this layer, but in different parts of it. Of CVE-2026-19478 GitLab writes that an issue under certain conditions could have allowed an unauthenticated user to remotely modify or delete public projects and user data through a GraphQL directive. The flaw is classified as CWE-94, code injection, and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H expresses an attack over the network, without privileges and without user interaction, with high damage to integrity and availability. One discrepancy the sources leave unexplained is worth noting: the title says code injection, while the vector records only limited loss of confidentiality. GitLab names neither the directive nor the code path, and states that the technical issues become public only 90 days after the release.

The second vulnerability, CVE-2026-19650, carries a CVSS score of 7.1 and a severity of high. It sits in the handling of multiplex queries, meaning several GraphQL queries packed into one request. GitLab writes that insufficient request validation under certain conditions could have allowed an unauthenticated user to perform mutations through GET requests. A mutation is the part of GraphQL that changes data, and GET is the method every link in the chain treats as harmless. Browsers, proxies and link previews fetch GET addresses freely, precisely because they are not supposed to change anything. The flaw is classified as CWE-352, cross site request forgery, and its vector requires user interaction. Both flaws were reported through GitLab's HackerOne programme, by hiimguardian and kreep. None of the sources mentions exploitation, and the CVE records carry an assessment from CISA stating that exploitation has not been observed. There are no interim measures, only the upgrade.

What this means for you if you run GitLab yourself

The dividing line in this case runs between you and those who use GitLab.com. On the cloud delivered service this is already handled without you lifting a finger. If you run GitLab yourself the opposite holds: nobody has upgraded on your behalf, and there is no workaround to put in place while you wait. Our assessment is that the urgency here does not come from observed exploitation, because no source records any. It comes from the fix being public. From the moment a fix ships, anybody can compare the code before and after and find the way in themselves. GitLab holds the technical detail back for 90 days for exactly that reason, but the code itself is not secret.

Consider for a moment what a GitLab installation actually holds. It holds the source code, the build jobs, the tokens to the production environment and the history of everything you have made. A flaw that can modify or delete public projects without authentication therefore touches both the availability of that work and the confidence that the code is the same today as it was yesterday. If your organisation is covered by NIS2, a code platform belongs among the systems where you have to show both that updates go in quickly and that changes to code can be traced. If you keep backups of the GitLab installation, this is a good occasion to confirm that they actually restore, and not merely that the job ran.

Berigo recommends

• Upgrade to 19.2.4, 19.1.6, 19.0.8 or 18.11.11, depending on the release line you run. GitLab offers no interim measures.
• The upgrade needs no database migrations and, according to GitLab, should require no downtime for multi node installations. Use that against any argument for postponing it.
• Check whether the GitLab interface is reachable from the internet, and restrict it to the networks that genuinely need access.
• Review what is marked as public projects in the installation. The more serious flaw targets precisely those.
• Confirm that the backup of the installation can actually be restored, and not merely that the job finished without errors.