Introduction
A missing CSRF check on GitLab's GraphQL API means that any authenticated user who visits a malicious web page could unknowingly execute mutations against their own GitLab instance, such as modifying repository settings or altering project configurations. GitLab CE/EE is one of the most widely deployed DevOps platforms, and the vulnerable version range stretches back to 17.0, so the exposure surface for self-managed installations is substantial.
Technical Information
Root Cause
The vulnerability (CWE-352) is in GitLab's /api/graphql endpoint. GraphQL mutations are the operations used to create, update, or delete data. The endpoint did not properly validate the origin of incoming state-changing requests, which means it did not enforce anti-forgery token checks on mutation operations. This is a classic CSRF gap. The server trusts that any request carrying valid session cookies was intentionally issued by the authenticated user, and it never verifies that the request actually came from a legitimate GitLab page.
CVSS Breakdown
The CVSS 3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, which gives a base score of 8.1 (High).
| Metric | Value | Implication |
|---|---|---|
| Attack Vector (AV) | Network (N) | Exploitable remotely over the internet |
| Attack Complexity (AC) | Low (L) | No specialized access conditions required |
| Privileges Required (PR) | None (N) | The attacker does not need prior authentication |
| User Interaction (UI) | Required (R) | A victim must interact with malicious content |
| Confidentiality (C) | High (H) | Total loss of confidentiality for the affected user session |
| Integrity (I) | High (H) | Total loss of integrity; unauthorized data modification |
| Availability (A) | None (N) | No direct impact on system availability |
The attacker needs zero privileges on the target system. The only prerequisite is that an authenticated GitLab user visits attacker-controlled content.
Attack Flow
-
Reconnaissance: The attacker identifies a self-managed GitLab instance and determines that it runs a vulnerable version (17.0 through 18.11.0, 18.10.0 through 18.10.3, or 18.9.0 through 18.9.5).
-
Payload crafting: The attacker builds a malicious HTML page with a form or JavaScript that submits a GraphQL mutation request to the target's
/api/graphqlendpoint. The mutation could target any writable operation exposed through the GraphQL schema. -
Delivery: The attacker distributes the page through phishing email, a compromised website, or any channel that users authenticated to the target GitLab instance are likely to visit.
-
Execution: When an authenticated GitLab user visits the page, the browser automatically attaches the user's valid session cookies to the forged request. Because the GraphQL endpoint lacks proper anti-forgery token validation, the GitLab server processes the mutation as a legitimate authenticated request.
-
Impact: The attacker's chosen mutation runs under the victim's identity. Depending on the victim's permissions, this could mean modifying repository settings, changing project configurations, updating user account details, or any other write operation available through the GraphQL API.
The confidentiality impact is rated High because GraphQL mutations can return sensitive data in their responses. The integrity impact is High because the attacker can make arbitrary modifications within the scope of the victim's permissions.
Patch Information
GitLab patched CVE-2026-4922 in a coordinated security release published on April 22, 2026. The fix ships in three concurrent patch versions covering both the Community Edition (CE) and the Enterprise Edition (EE):
| Release Train | Fixed Version | Vulnerable Range |
|---|---|---|
| 18.11.x | 18.11.1 | 18.11.0 |
| 18.10.x | 18.10.4 | 18.10.0 to 18.10.3 |
| 18.9.x | 18.9.6 | 17.0.0 to 18.9.5 |
The patch strengthens how the API verifies request origins, so it now rejects mutation requests that lack valid anti-forgery tokens.
Deployment considerations:
- GitLab.com (SaaS): Already running the patched code. No user action required.
- GitLab Dedicated: Managed by GitLab. No customer action required.
- Self-managed installations: Upgrade to one of the three fixed versions as soon as possible. These patch releases include database migrations, so single-node instances will have some downtime during the upgrade. Multi-node deployments that follow GitLab's zero-downtime upgrade procedures can apply the patch without service interruption.
Security researcher ahacker1 initially reported the vulnerability through GitLab's HackerOne bug bounty program (report #3627285). GitLab has filed a corresponding internal work item (#594937), which remains confidential. Under GitLab's disclosure policy, full technical details will go public on its issue tracker 30 days after this patch release.
Affected Systems and Versions
The vulnerability affects all GitLab CE/EE versions from 17.0 onward that have not been updated to one of the three fixed releases:
- GitLab CE/EE 17.0.0 through 18.9.5 (fixed in 18.9.6)
- GitLab CE/EE 18.10.0 through 18.10.3 (fixed in 18.10.4)
- GitLab CE/EE 18.11.0 (fixed in 18.11.1)
GitLab.com and GitLab Dedicated environments are already patched and are not affected. Only self-managed installations running versions in the ranges above are vulnerable.
Administrators should check their current GitLab version against these ranges. Any self-managed instance that runs an affected version and exposes the GraphQL API (enabled by default) is susceptible.
Vendor Security History
GitLab has a structured security release process, with scheduled patch releases twice a month and ad hoc critical patches for high-severity vulnerabilities. It also runs a bug bounty program through HackerOne, which is how CVE-2026-4922 was identified and responsibly disclosed. An earlier CSRF issue on the /api/graphql endpoint was tracked in GitLab issue #324397, which suggests that CSRF protection on the GraphQL layer is a recurring concern for the GitLab security team.
GitLab makes vulnerability details public on its issue tracker 30 days after the patch release, which gives administrators a defined remediation timeline. The policy balances transparency with time to patch, but it also means detailed exploitation information will become publicly available, so a timely upgrade is essential.
