GitLab GraphQL flaw lets an unauthenticated attacker delete your public projects (CVE-2026-19478)

A code host is the one server a team assumes it can trust with its own history. CVE-2026-19478 breaks that assumption in the worst way. Under the right conditions it lets someone who never logged in reach into a self-managed GitLab and erase public projects, and the accounts behind them, outright. GitLab rated it 9.4 and shipped an emergency fix this week. Most of the critical bugs we have written up this year were about reading data you should not see or running code you should not run. This one is different: it destroys, and destruction of your source of truth is an availability and integrity event, not a leak.

What CVE-2026-19478 actually does

GitLab's own advisory keeps it terse: given the right preconditions, someone with no account can reach the GraphQL API and either alter or wipe public projects and the records tied to them. No credentials, no session, no push access. The attacker sends a crafted GraphQL request and the server carries it out as if it were authorized. SecurityWeek classifies it as a code injection weakness; Security Affairs frames it as abuse of a GraphQL directive. Either way, the practitioner takeaway is the same: the GraphQL API accepted an operation it should have rejected.

The exposure is entirely on self-managed installations. GitLab.com, the hosted SaaS product, is not affected. The bug was reported through GitLab's HackerOne program by a researcher going by hiimguardian. There is no confirmed exploitation in the wild yet, but that window is closing quickly: proof-of-concept code referencing the CVE has already started to appear on public repositories within a day of the fix. That is exactly the point to patch inside, not after.

Affected versions and the patch

Every self-managed release from 18.2 through 19.2, across both Community and Enterprise editions, is vulnerable. GitLab shipped the fix across its supported branches: 19.2.4 on the 19.2 line, 19.1.6 on 19.1, 19.0.8 on 19.0, and 18.11.11 on the 18.11 branch. The detail that will bite the slowest movers: versions 18.2 through 18.10 get no in-branch patch at all. If you are on one of those, there is no point release coming to save you; you have to upgrade to a patched branch.

The same release also addresses CVE-2026-19650, a CSRF weakness (CVSS 7.1) in how GitLab handles GraphQL multiplex queries, which can let an unauthenticated GET request trigger a mutation. It is the lower-severity sibling, but it is in the same subsystem and it ships in the same upgrade, so there is no reason to treat it separately.

Why "delete" is worse than "read" here

Read-and-leak bugs are bad, but they leave the original intact. A destructive unauthenticated bug on a code host attacks the thing your recovery plan depends on. If an attacker erases public projects and the accounts attached to them, the immediate damage is lost work and broken references, and the secondary damage reaches everyone downstream. Anything that pulls from a public project on that instance, a pipeline, a submodule, a dependency mirror, suddenly points at something that vanished or changed. That is a supply-chain integrity problem wearing a data-loss costume.

There is a nastier failure mode for teams that automate backups. If your instance replicates or syncs its state to a backup target on a schedule, a mass deletion can propagate into that target before anyone notices, quietly overwriting the last known good copy with the damaged one. The clean snapshot you want is the one taken before you patched and before any attacker touched the box.

GitLab's GraphQL surface keeps producing criticals

This is the third serious GitLab issue we have covered in about eight weeks. In late July a notebook-diff flaw let any user with push access run code on the server, with a public exploit already circulating. In June, a no-login flaw let an attacker hijack a user's session, and self-hosted servers were again the exposed ones. Two of those three sit in the API and authorization layer, and this one lives in GraphQL specifically. The pattern worth internalizing is that GitLab's GraphQL endpoint is a repeatedly productive target, not an internal convenience you can treat as low risk. If you run self-managed GitLab, the GraphQL API deserves the same scrutiny as any internet-facing authentication surface.

What to do this week

Patching is the whole fix, but the order matters when the payload is deletion.

• Upgrade to your branch's patched release now using the version table above. If you are on 18.2 through 18.10, schedule the branch upgrade this week rather than waiting for a point release that is never coming.

• Take a verified backup before you upgrade. A destructive bug makes your backup the recovery plan, so you want a clean snapshot from before the patch window, and you want to confirm it restores.

• Cut the attack surface. If the instance does not need to face the public internet, put it behind a VPN or an IP allowlist. Unauthenticated plus internet-reachable is the worst case for a bug like this.

• Detect now, even without a proof-of-concept. Watch your GitLab production and audit logs for unauthenticated GraphQL requests to the API endpoint, unexpected project-deletion and destroy mutations, GET requests that carry GraphQL mutations (the CSRF sibling), and any spike in project or user deletions. Those are the signatures of this class of abuse whether or not the specific exploit is public.

• Mind the disclosure clock. GitLab publishes full technical details on a delay after a fix, so expect reverse-engineering and opportunistic scanning once the specifics land. Patched-in-days is the right posture, not patched-this-quarter.