Critical GitLab Flaw Lets Attackers Wipe Public Projects Without Logging In

Key points

• GitLab has patched a critical flaw tracked as CVE-2026-19478, rated 9.4 out of 10 on the industry severity scale.
• The bug affects both GitLab Community Edition and Enterprise Edition, the free open-source and paid commercial versions of the developer platform.
• An attacker with no account could remotely change or delete public projects and user data under certain conditions.
• GitLab rates the issue Critical and is urging self-managed customers to update immediately.

GitLab has shipped emergency fixes for a serious flaw in the software that millions of developers use to store and collaborate on source code.

The bug is tracked as CVE-2026-19478 and carries a severity score of 9.4 out of 10. That puts it firmly in the patch-now category.

What makes this one uncomfortable is that an attacker doesn't need an account. Under the right conditions, someone with no login could reach in over the internet and modify or delete public projects, along with data belonging to their users.

What is actually broken?

The flaw sits in GraphQL, the query system GitLab uses to let apps and browsers ask its servers for data. Think of it as the counter clerk that takes requests and hands back files. In this case, the clerk was handing out write access to people who should never have been let past the door.

GitLab hasn't published deep technical detail, which is standard practice while customers are still patching. It describes the issue as affecting both Community Edition and Enterprise Edition. We covered a related GitLab exposure on 25 July in "GitLab Flaw Lets Any Logged-In User Run Commands on Self-Hosted Servers", where working exploit code appeared publicly within days of disclosure; that pattern is worth keeping in mind here.

Who is affected?

Anyone running their own GitLab server needs to update. GitLab.com, the hosted service GitLab runs itself, is already patched, so users of the cloud version don't need to do anything.

Self-managed installs are the concern. Universities, government bodies, financial institutions and tech companies all commonly run their own GitLab servers behind the firewall or on cloud infrastructure they control. Those admins carry the responsibility to apply the fix.

Is this being exploited yet?

GitLab hasn't linked this bug to any named attack group or intrusion set. No vendor has claimed in-the-wild exploitation at the time of writing. Treat capability and intent as separate things: the capability is now documented, and that alone tends to attract opportunistic scanning within days of a patch.

Source code platforms are a high-value target. Prior incidents against similar systems have been used to plant backdoors in software supply chains, so the risk isn't only lost data. It's altered code that downstream users would then trust.

What should admins do now?

Apply the update. GitLab publishes fixed versions for each supported release branch on its own security releases page, and self-managed operators should move to a patched build without waiting for a maintenance window if their instance is reachable from the internet.

After patching, review recent GraphQL activity in logs for unexpected mutation calls, the requests that change data rather than read it. Anything that looks like edits from unauthenticated sessions deserves a closer look.

Ordinary developers with accounts on someone else's GitLab don't need to act. If your employer runs its own server, expect a brief outage while admins update.

The no-authentication requirement is what pushes this above the usual critical-patch noise. An exploit doesn't need a stolen credential or a phishing campaign to get started. Watch for proof-of-concept code appearing publicly in the next few days.