Self-Hosted GitLab Needs an Immediate Update for a Critical Unauthenticated Flaw
If you run GitLab yourself, this is one of those updates that should move to the top of the list.
GitLab released a critical patch on August 17 for Community Edition and Enterprise Edition after fixing two security problems in its GraphQL interface. The more serious of the two, CVE-2026-19478, has a CVSS severity score of 9.4 out of 10. Under certain conditions, GitLab says an attacker who is not logged in can remotely modify or delete public projects and user data.
GraphQL is simply one of the ways software can ask GitLab for information or tell it to do something. You do not need to understand GraphQL to understand the problem here: a part of GitLab that accepts structured requests was not enforcing the boundaries it was supposed to enforce. That is especially unpleasant in a product whose entire job is storing source code, project history, issues, and other information a development team depends on.
The affected releases are GitLab 18.2 through versions before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. A second vulnerability, CVE-2026-19650, is rated 7.1 and could allow unauthorized GraphQL mutations through specially constructed requests.
There is an important distinction here. This is primarily a problem for self-managed GitLab. GitLab says GitLab.com and GitLab Dedicated have already been patched, so customers using those hosted services do not need to do anything. GitLab also says the patch does not introduce new database migrations and that multi-node deployments generally should not require downtime.
SecurityWeek noted that GitLab’s advisory does not say either flaw is being actively exploited in the wild. That is good news, but it is not a reason to wait. Once a vendor publishes enough information to tell everyone a remotely reachable, unauthenticated 9.4-severity bug exists, the clock is running. Attackers get the advisory too.
If your business, development team, or client environment runs its own GitLab server, check the installed version and update to the patched release for your branch now. This is exactly the sort of maintenance that is boring right up until it becomes very exciting for all the wrong reasons.