GitLab fixes high‑severity GraphQL bug

GitLab just fixed a bug where a logged-in user could use a live WebSocket connection to reach server methods they were not supposed to touch. GitLab shipped the fix on April 8, 2026 in versions 18.10.3, 18.9.5, and 18.8.9. (about.gitlab.com) GitLab is the software many companies use to store code, run build pipelines, and manage deployments on their own servers. When a self-hosted GitLab box is exposed to the internet, a bug in its access checks can turn one normal user account into a much bigger problem. (about.gitlab.com) The weak spot was GraphQL, which is an interface that lets an app ask for exactly the data it wants instead of loading whole pages. In GitLab, GraphQL also supports subscriptions, which keep a connection open so the server can push updates back in real time. (docs.gitlab.com) That always-open link runs over WebSockets, which work more like a phone call than a one-time letter. The flaw sat in that WebSocket path, where GitLab said improper access control could let an authenticated user invoke unintended server-side methods. (about.gitlab.com) GitLab assigned the bug CVE-2026-5173 and rated it High severity. The published Common Vulnerability Scoring System score was 8.5, with low attack complexity, no user interaction, and only low privileges required. (tenable.com) The affected range was wide: every GitLab Community Edition and Enterprise Edition release from 16.9.6 up to, but not including, 18.8.9 was vulnerable, along with 18.9 releases before 18.9.5 and 18.10 releases before 18.10.3. That means many organizations could be exposed even if they were only a few patch versions behind. (tenable.com) A public GitLab issue from 2025 described the core mistake in plain terms: the normal GraphQL controller checked whether a blocked user could access the application programming interface, but the subscription channel used Action Cable, the WebSocket system in Ruby on Rails, and skipped that check. In other words, the front door had a guard, but the side door handling live updates did not. (gitlab.com) GitLab’s advisory says the bug could let an authenticated user invoke unintended methods, and outside writeups describe the likely result as sensitive data exposure with some limited unauthorized actions. The scoring also points in that direction, with high confidentiality impact and low integrity impact rather than a full system takeover. (about.gitlab.com) (tenable.com) (justappsec.com) GitLab said GitLab.com and GitLab Dedicated were already running patched code in its April 8 release process. The urgent work is for teams running self-managed GitLab, because they control their own upgrade window and internet exposure. (about.gitlab.com) The practical check is simple: if a server is on 18.10, it should be at 18.10.3 or later; if it is on 18.9, it should be at 18.9.5 or later; if it is on 18.8, it should be at 18.8.9 or later. Anything older in the affected branches needs the April 8, 2026 security update. (docs.gitlab.com)