GitLab has rolled out fixes for two security issues that affect its GraphQL functionality. One of them is rated critical and can be exploited without authentication, while the other addresses a cross-site request forgery (CSRF) weakness related to the GraphQL multiplex query handler.
In an advisory, GitLab identifies the issues as CVE-2026-19478 (CVSS 9.4) and CVE-2026-19650 (CVSS 7.1). Both are addressed in specific Community Edition (CE) and Enterprise Edition (EE) releases.
Critical GraphQL code injection: CVE-2026-19478
The most severe problem reported by GitLab is CVE-2026-19478, which carries a critical severity score of CVSS 9.4. According to the advisory, attackers can abuse a GraphQL directive to modify or delete user data and public projects—and the flaw can be exploited without authentication under certain conditions.
Because this weakness involves GraphQL query behavior, it is especially concerning for teams that expose GitLab’s web interface to broader networks. GitLab’s advisory also ties the impact to how the affected GraphQL functionality processes directives, which can open the door to unexpected actions beyond normal user permissions.
CSRF issue in GraphQL multiplex handling: CVE-2026-19650
The second vulnerability GitLab patched is CVE-2026-19650 with a CVSS 7.1 rating. This issue relates to cross-site request forgery (CSRF) and affects the GraphQL multiplex query handler.
GitLab explains that, in certain scenarios, an unauthenticated user could execute mutations via GET requests. The root cause is described as improper request validation within the GraphQL multiplex query handling logic.
In practice, CSRF-style problems often hinge on how a server validates requests and whether it can reliably distinguish legitimate traffic from requests triggered in other contexts. By addressing the validation behavior, GitLab aims to prevent mutation execution through the problematic request pattern.
Which GitLab versions are affected?
GitLab states that both security defects impact all GitLab Community Edition (CE) and Enterprise Edition (EE) versions starting from these branches and ranges:
- 18.2 onward
- 19.0 onward
- 19.1 onward
- 19.2 onward
Put differently, if your GitLab instance runs a release in these tracks but not the patched version listed by GitLab, you should treat it as vulnerable until the upgrade is completed.
Fixed versions for GitLab CE/EE
To remediate the issues, GitLab provides patched builds for each affected line. The fixed versions are:
- GitLab CE/EE 18.11.11
- GitLab CE/EE 19.0.8
- GitLab CE/EE 19.1.6
- GitLab CE/EE 19.2.4
GitLab recommends that all self-managed installations be upgraded immediately to one of these versions.
What about GitLab.com and GitLab Dedicated?
Not every GitLab user needs to take action. GitLab states that the patches were automatically applied to:
- GitLab.com
- GitLab Dedicated
For organizations using these hosted offerings, GitLab indicates there is no separate upgrade step required on the user side.
How the vulnerabilities were reported
GitLab notes that both security defects were reported through its HackerOne bug bounty program. The advisory does not suggest any public, widespread exploitation, and GitLab does not mention that either vulnerability has been exploited in the wild.
Even when active exploitation is not confirmed, critical vulnerabilities—particularly those rated 9.4 and reachable without authentication—typically deserve rapid patching to reduce exposure time.
Why these issues matter for teams
Both vulnerabilities center on GraphQL request handling, which means they may affect applications and integrations that rely on GitLab’s API and web endpoints. When a code injection flaw can be triggered without authentication, it raises the stakes beyond typical account-scoped risks.
Similarly, the CSRF-related bug highlights that request validation and HTTP method handling remain critical controls. If a service accepts unexpected request patterns, attackers may find a way to perform actions that should require stronger assurances.
Recommended next steps
If you run GitLab yourself, the most important step is clear: upgrade to the fixed CE/EE versions provided by GitLab. Beyond that, consider the following practical checks:
- Verify your current version and compare it to the fixed releases listed in the advisory.
- Confirm your upgrade plan with change-management procedures, especially if you manage a heavily used instance.
- Check access exposure around GitLab’s web endpoints, particularly if external requests are allowed.
- Monitor logs after the upgrade for unusual GraphQL traffic patterns.
For hosted users on GitLab.com or GitLab Dedicated, GitLab’s automated patching covers the remediation, but teams may still want to document the event for their internal security records.
Bottom line
GitLab has patched two GraphQL-related vulnerabilities: a critical-severity code injection issue (CVE-2026-19478, CVSS 9.4) that can be abused without authentication, and a CSRF weakness (CVE-2026-19650, CVSS 7.1) affecting GraphQL multiplex query handling. GitLab urges self-managed customers to upgrade immediately to the specified CE/EE fixed versions.
With the patches already applied to GitLab.com and GitLab Dedicated, the urgency mainly falls on organizations running their own GitLab instances. If you are in that category, upgrading now is the most direct way to reduce risk.
Source: https://www.securityweek.com/gitlab-patches-critical-code-injection-vulnerability/
