GitLab — GitLab Critical Patch Release: 19.2.4, 19.1.6, 19.0.8, 18.11.11

GitLab Critical Patch Release: 19.2.4, 19.1.6, 19.0.8, 18.11.11

On August 17, 2026, we released versions 19.2.4, 19.1.6, 19.0.8, 18.11.11 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important bug and security fixes, and we…

Security 2
  • Remediated a code injection issue via GraphQL directive that could allow an unauthenticated user to remotely modify or delete public projects and user data
  • Remediated a Cross-Site Request Forgery issue in GraphQL multiplex query handler that could allow an unauthenticated user to execute mutations via GET requests due to improper request validation

Help us learn about your current experience with the documentation. Take the survey.

GitLab Critical Patch Release: 19.2.4, 19.1.6, 19.0.8, 18.11.11

On August 17, 2026, we released versions 19.2.4, 19.1.6, 19.0.8, 18.11.11 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately. GitLab.com and GitLab Dedicated are already running the patched version. GitLab.com and GitLab Dedicated customers do not need to take action. GitLab releases fixes for vulnerabilities in patch releases. There are two types of patch releases: scheduled releases and ad-hoc critical patches for high-severity vulnerabilities. Scheduled releases are released twice a month on the second and fourth Wednesdays. For more information, please visit our releases handbook and security FAQ. You can see all of GitLab release blog posts here. For security fixes, the issues detailing each vulnerability are made public on our issue tracker 90 days after the release in which they were patched. We are committed to ensuring that all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards. To maintain good security hygiene, it is highly recommended that all customers upgrade to the latest patch release for their supported version. You can read more best practices in securing your GitLab instance in our blog post.

Recommended Action

We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible. When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, it means all types are affected.

Security fixes
Table of security fixes

TitleSeverity Code Injection issue via GraphQL directive impacts GitLab CE/EECritical Cross-Site Request Forgery issue in GraphQL multiplex query handler impacts GitLab CE/EEHigh

CVE-2026-19478 - Code Injection issue via GraphQL directive impacts GitLab CE/EE

GitLab has remediated an issue that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive. Impacted Versions: GitLab CE/EE: all versions from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4CVSS 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H) Thanks hiimguardian for reporting this vulnerability through our HackerOne bug bounty program.

CVE-2026-19650 - Cross-Site Request Forgery issue in GraphQL multiplex query handler impacts GitLab CE/EE

GitLab has remediated an issue that under certain conditions could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling. Impacted Versions: GitLab CE/EE: all versions from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) Thanks kreep for reporting this vulnerability through our HackerOne bug bounty program.

Important notes on upgrading

These versions do not include any new migrations, and for multi-node deployments, should not require any downtime. Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates.

Updating

To update GitLab, see the Update page. To update GitLab Runner, see the Updating the Runner page.

Receive Patch Notifications

To receive patch blog notifications delivered to your inbox, visit our contact us page. To receive release notifications via RSS, subscribe to our patch release RSS feed or our RSS feed for all releases.

View original

Upgraded? How did it go?

Discussion