Critical GitLab Flaw Lets Attackers Wipe Public Projects Without Logging In
GitLab has patched a flaw rated 9.4 out of 10 that let unauthenticated attackers alter or delete public projects and user data through the platform's GraphQL interface.
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 and paid versions of the developer platform.
- Under certain conditions an attacker who is not logged in could remotely change or delete public projects and user data.
- 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. It carries a severity score of 9.4 out of 10, which puts it firmly in the "patch now" category.
What makes this one uncomfortable is that an attacker does not need an account. Under the right conditions, someone with no login at all 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, the ability to change or delete things, to people who should never have been let past the door.
GitLab has not published deep technical detail, which is standard practice while customers are still patching. The company describes the issue as affecting both Community Edition, the free open-source version, and Enterprise Edition, the paid commercial version. The flaw was first reported by The Hacker News.
Who is affected?
Anyone running their own GitLab server needs to update. GitLab.com, the hosted service GitLab runs itself, is already patched on the company's side, so individual users of the cloud version do not need to do anything.
Self-managed installs are the concern. Universities, government agencies, banks 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.
| Detail | Value |
|---|---|
| CVE ID | CVE-2026-19478 |
| Severity score | 9.4 (Critical) |
| Affected products | GitLab CE and EE (self-managed) |
| Attacker needs login? | No |
| Impact | Modify or delete public projects and user data |
Is this being exploited yet?
GitLab has not linked this bug to any named attack group or intrusion set. There is no public reporting tying it to activity clusters like the ones tracked as [redacted], and 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, which 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 concern is not only lost data but 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, which are the requests that change data rather than just read it. Anything that looks like edits from unauthenticated sessions deserves a closer look.
Ordinary developers with accounts on someone else's GitLab do not need to take action themselves. If your employer runs its own GitLab server, expect a brief outage notice while the admins update.
