GitLab has released an out-of-band security update to fix critical vulnerability CVE-2026-19478 with a CVSS score of 9.4, which under certain conditions allows an unauthenticated attacker to remotely modify or delete public projects and user data via a GraphQL directive. The vulnerability affects self-managed installations of GitLab Community Edition and Enterprise Edition from versions 18.2 through 19.2.3 inclusive. The cloud services GitLab.com and GitLab Dedicated have already been patched and do not require any user action. Administrators of self-managed instances must immediately update to versions 19.2.4, 19.1.6, 19.0.8 or 18.11.11.
Technical details of the vulnerabilities
CVE-2026-19478 — remote data modification without authentication
The critical vulnerability CVE-2026-19478 has been given a CVSS score of 9.4 by GitLab. According to the published CVSS vector, exploitation is possible over the network, does not require credentials, and does not involve any interaction from the victim. GitLab describes the issue as allowing an unauthenticated user “to remotely modify or delete public projects and user data via a GraphQL directive.”
The specific GraphQL directive used in the attack and the exact conditions required for exploitation have not been disclosed. As of the time the patch was released, no instances of active exploitation had been recorded, and the vulnerability has not been added to the CISA KEV catalog.
Affected versions:
- All versions from 18.2 up to 18.11.11 (excluding 18.11.11)
- 19.0 up to 19.0.8
- 19.1 up to 19.1.6
- 19.2 up to 19.2.4
Important nuance: fixes have only been released for branches 18.11, 19.0, 19.1, and 19.2. Branches from 18.2 through 18.10 fall within the vulnerable range, but no patches are provided for them. Organizations using these versions must upgrade to one of the fixed branches.
CVE-2026-19650 — CSRF in the GraphQL multiplex query handler
The second fix in this release addresses CVE-2026-19650, a cross-site request forgery (CSRF) vulnerability with a CVSS score of 7.1 (High). The issue is related to improper validation of requests in the GraphQL multiplex query handler, which allowed an unauthenticated user to perform mutations via GET requests. Unlike the critical vulnerability, exploitation of CVE-2026-19650 requires user interaction — a typical scenario for CSRF attacks, where the victim has to follow a malicious link.
Impact assessment
The combination of two factors makes CVE-2026-19478 particularly dangerous: no authentication is required, and it enables destructive actions — deleting projects and user data. For organizations using self-managed GitLab with publicly accessible projects, this creates a direct risk of losing code, CI/CD artifacts, pipeline configurations, and related data.
The range of affected versions spans more than a year of releases — from 18.2 to the current 19.2 — which indicates broad distribution of the vulnerable code. Organizations that have delayed updating and remain on older branches 18.2–18.10 find themselves in the most difficult position: for them, the only path is migration to a supported branch.
The fact that GitLab released a patch outside its standard update schedule underscores how serious the vendor considers this issue to be.
Recommendations
- Immediately update self-managed GitLab instances to versions 19.2.4, 19.1.6, 19.0.8, or 18.11.11. GitLab notes that the update does not introduce new migrations and does not require downtime for multi-node deployments.
- Check your current version via the GitLab administrative panel or by running the command
gitlab-rake gitlab:env:info. - If your instance is running on branches 18.2–18.10, plan a migration to branch 18.11 or later, since no patches have been released for these branches.
- Before updating, consider restricting network access to the GitLab GraphQL endpoint using network filtering tools — this will reduce the attack surface for CVE-2026-19478.
- Audit public projects for unauthorized changes or deletions during the period leading up to patch installation.
Given the CVSS 9.4 score, the lack of authentication requirements, and the destructive potential of CVE-2026-19478, updating self-managed GitLab instances to the patched versions should be treated as a high priority — before the technical details of the vulnerability are published, which, according to GitLab’s disclosure policy, may occur within 90 days of the patch release.
