GitLab's CVSS 10 fix lives in the CI config parser

The server reads your CI configuration before any runner sees it. (Most of us forget that it gets parsed on the server at all.) On 12 October GitLab shipped critical patch releases 19.4.2, 19.3.5 and 19.2.8 for Community and Enterprise Edition, and the top fix sits in exactly that layer. CVE-2026-97229 is an integer overflow in the CI/CD regular expression compiler, rated CVSS 10.0.

According to the advisory, under certain conditions an unauthenticated user could execute arbitrary code on the GitLab server by putting a specially crafted regular expression in a CI/CD configuration, because regex validation was insufficient. Affected versions are 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. The reporter, joaxcar, came through GitLab's HackerOne program. GitLab.com already runs the fix, and Dedicated customers have nothing to do. If you run self-managed GitLab, the upgrade is your job.

Check the version numbers on your upgrade ticket. GitLab first patched the 19.3 line as 19.3.4, but that build broke merge request pages on instances with the Ona integration enabled, so 19.3.5 replaces it. If your ticket says 19.3.4, change it to 19.3.5.

Two more fixes aimed at pipelines

The 10.0 gets the headline, but two of the High-rated fixes hit the same trust boundary:

• CVE-2026-16301 (CVSS 8.5). A user with the Developer role could run CI/CD pipelines on protected branches without authorization, through the downstream pipeline creation service. Protected branches are usually where the deploy credentials live.
• CVE-2026-14814 (CVSS 8.2). Poisoned cached responses for raw repository files could make a targeted user's pipelines execute crafted content, potentially exposing protected environment variables.

The list also includes CVE-2026-92883 (CVSS 8.7), cross-site scripting in syntax highlighting through a crafted repository, along with a long tail of Medium and Low authorization fixes.

Budget for the migration

This patch includes database migrations. Single-node instances will be down until the migrations finish. Multi-node installs that follow GitLab's zero-downtime upgrade procedure can avoid the outage, and 19.3.5 also carries post-deploy migrations that can run after the upgrade.

My verdict: patch today, and on a single-node instance plan for a short outage. An unauthenticated path to code execution on the machine that holds every project's CI secrets is not something to leave for the next maintenance window. Every pipeline you run starts with a server parsing YAML, so make sure that server is patched.