Introduction
A recently patched access control flaw in GitLab's WebSocket connection layer let any authenticated user, even one with minimal privileges, invoke internal server-side methods that should never have been reachable. On self-managed GitLab instances, this vulnerability (CVE-2026-5173, CVSS 8.5) exposed sensitive data, along with a limited ability to modify it, to anyone with a valid login. The vulnerable code has been present since the 16.9.x release series, a span of over two major version cycles.
Technical information
Root cause: CWE-749 and exposed server-side methods
CVE-2026-5173 falls under CWE-749: Exposed Dangerous Method or Function. GitLab's WebSocket endpoint did not sufficiently restrict which internal methods incoming connections could call. In CWE-749 terms, the product offers an interface to external actors, and that interface includes dangerous methods without proper restriction. Exposing critical functionality this way gives an attacker the privilege level of whatever is exposed, which could lead to the modification or exposure of sensitive data.
In practice, the WebSocket connection handler accepted method invocations from authenticated clients without checking whether the calling user was authorized to reach those specific server-side operations. A user with only basic authentication (low privileges) could craft WebSocket messages aimed at internal methods that were meant for higher privilege levels or for internal system use only.
CVSS profile and attack characteristics
The CVSS 3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, for a score of 8.5 HIGH. The individual metrics break down as follows:
| Metric | Value | Technical Implication |
|---|---|---|
| Attack Vector (AV) | Network (N) | Exploitable remotely over a network connection |
| Attack Complexity (AC) | Low (L) | No advanced conditions or complex security bypasses required |
| Privileges Required (PR) | Low (L) | Attacker must be authenticated but only needs basic user privileges |
| User Interaction (UI) | None (N) | No action required from a victim user |
| Scope (S) | Changed (C) | Impact extends beyond the vulnerable authorization scope |
| Confidentiality (C) | High (H) | Total loss of confidentiality for affected data |
| Integrity (I) | Low (L) | Some data modification possible, but not total control |
| Availability (A) | None (N) | No disruption to service availability |
The "Changed" scope means a successful exploit lets the attacker affect components beyond the vulnerable WebSocket handler itself, reaching parts of the GitLab system that the attacker's authorization context should not permit.
Attack flow
Based on the advisory details and the CWE classification, exploitation follows this general sequence:
- The attacker authenticates to the GitLab instance with a low-privilege account (any valid user account suffices).
- The attacker opens a WebSocket connection to the GitLab server through the normal WebSocket endpoint.
- Over that connection, the attacker sends messages that invoke server-side methods not intended for their privilege level.
- Because the WebSocket handler does not enforce access control on which methods can be called, the server executes the requested operations.
- The attacker gains access to sensitive information (high confidentiality impact) and may be able to modify some data (low integrity impact) that should be outside their authorization scope.
With low attack complexity and no user interaction required, this vulnerability is straightforward to exploit once an attacker has any authenticated session.
Patch information
GitLab addressed CVE-2026-5173 in a coordinated security patch release published on April 8, 2026. The release ships fixes on three supported version tracks for both GitLab Community Edition (CE) and Enterprise Edition (EE):
| Product | Affected Version Range | Fixed Version |
|---|---|---|
| GitLab CE/EE | 18.10 before 18.10.3 | 18.10.3 |
| GitLab CE/EE | 18.9 before 18.9.5 | 18.9.5 |
| GitLab CE/EE | 16.9.6 before 18.8.9 | 18.8.9 |
GitLab.com (the SaaS offering) was already running the patched version when the release was announced, and GitLab Dedicated customers required no action.
The fix tightened access control enforcement on the WebSocket connection handler. The patch restricts which methods WebSocket messages can invoke, so only explicitly authorized operations are reachable. This is the classic remediation for CWE-749: reduce the attack surface by whitelisting or gating the methods exposed to external callers, instead of assuming nobody will discover or call the internal ones.
Upgrade notes for self-managed instances:
- This patch release includes no database migrations, so multi-node deployments can upgrade without downtime.
- All deployment types are affected: Omnibus, source code, and Helm chart installations.
- GitLab skipped version numbers 18.10.2, 18.9.4, and 18.8.8, so administrators should update directly to 18.10.3, 18.9.5, or 18.8.9 respectively.
- By default, Omnibus packages will stop, run migrations, and start again regardless of the upgrade size. Administrators can change this behavior by adding a specific configuration file that skips auto reconfiguration during updates.
GitLab tracks the technical details in work item gitlab.com/gitlab-org/gitlab/-/work_items/588959. The issue is confidential for now. Under GitLab's standard security disclosure policy, it will become public on the GitLab issue tracker approximately 30 days after the patch release (around May 8, 2026), and the exact code-level diff will then be available for review.
GitLab has not documented any workarounds or temporary mitigations. The only vendor-supported remediation is applying the official patch.
Affected systems and versions
The vulnerability affects every deployment type of GitLab CE and EE (Omnibus, source code, and Helm chart) across a wide version range:
- GitLab CE/EE 16.9.6 through all versions before 18.8.9
- GitLab CE/EE 18.9.0 through versions before 18.9.5
- GitLab CE/EE 18.10.0 through versions before 18.10.3
The vulnerable code path was introduced approximately in the 16.9.x series and persisted for over two major version cycles. Any self-managed GitLab instance running a version in these ranges is affected. GitLab.com and GitLab Dedicated are not affected, because they have already been patched or require no action.
Vendor security history
GitLab follows a structured security release cadence, typically shipping scheduled patch releases twice a month, on the second and fourth Wednesdays. The company also runs a mature bug bounty program. In 2024, GitLab received 1,440 reports from 457 researchers and awarded over US$1 million in bounties across 275 valid reports.
GitLab team member Simon Tomlinson discovered CVE-2026-5173 internally. It did not surface through external threat actor activity or the bug bounty program. Because GitLab makes vulnerability details public 30 days after the patch release, organizations get a defined window to apply fixes before the technical details become widely available.
Threat intelligence
As of April 9, 2026, there is no evidence that CVE-2026-5173 is being actively exploited in the wild. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.
GitLab will make the detailed issue public approximately 30 days after the patch release, around May 8, 2026. Historically, the public release of vulnerability details speeds up the development of proof-of-concept exploits. Since exploitation has low attack complexity and needs nothing more than basic authentication, the time between now and that disclosure date is the critical period for patching self-managed instances.
