GitLab WebSocket flaw lets authenticated users invoke arbitrary server-side methods
TL;DR - CVE-2026-5173: GitLab CE/EE has insufficient access control on WebSocket connections. An authenticated user can invoke unintended server-side methods - potentially bypassing authorisation, performing privileged actions, or extracting sensitive data. Patch to 18.8.9, 18.9.5, or 18.10.3 depending on your release train.
What happened
GitLab CE/EE is the self-managed DevSecOps platform - source control, CI/CD, container registry, and secrets management all in one place. CVE-2026-5173 is an access control failure in how GitLab handles WebSocket connections.
The flaw allows an authenticated attacker to invoke server-side methods that should be off-limits. According to ASEC, this can be abused to bypass authentication checks, perform privileged actions, or disclose sensitive information.
The class of bug matters here. Authorisation logic in web applications is typically designed around HTTP request routing and controller-level checks. WebSocket connections establish a persistent, bidirectional channel that lives outside that flow. Access control gaps in real-time channels tend to be subtle, are harder to spot in logs, and often survive audits that focus on REST surfaces. On a platform where GitLab holds your source code, CI secrets, and deploy tokens, the exposure is meaningful.
Who is impacted
- Self-managed GitLab CE/EE instances in the affected version ranges.
| Release train | Affected versions | Fixed version |
|---|---|---|
| 16.9.x to 18.8.x | >= 16.9.6 and < 18.8.9 | 18.8.9 |
| 18.9.x | >= 18.9 and < 18.9.5 | 18.9.5 |
| 18.10.x | >= 18.10 and < 18.10.3 | 18.10.3 |
| Item | Detail |
|---|---|
| CVE | CVE-2026-5173 |
| Severity (CNA) | CVSS v3.1 8.5 (High) |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N |
| CWE | CWE-749 - Exposed Dangerous Method or Function |
What to do now
- Patch GitLab to the fixed version for your release train. Per the advisory: "affected GitLab instances need to be updated to the provided patch version."
- Inventory every instance in your fleet - production, staging, DR - and map each against the affected version ranges above.
- Treat the exposure as an authorisation surface problem, not just a routine upgrade:
- Review which GitLab instances face the internet versus internal networks only.
- Audit admin and maintainer role assignments against least-privilege expectations.
- Review compensating controls at the network edge (reverse proxy rules, allowlists, WAF policies) while the rollout proceeds.
- If you suspect the vulnerability has been misused, hunt around WebSocket-related access and anomalous privileged actions: admin configuration changes, project membership changes, token creation, and runner configuration modifications. Rotate any high-value credentials accessible from the affected GitLab instance.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.