GitLab Fixes CVSS 10 Flaw in CI/CD Regex Engine, Plus 23 Other Vulnerabilities

GitLab is telling every self-managed customer to upgrade now. On October 12, the company shipped versions 19.4.2, 19.3.5, and 19.2.8 of GitLab Community Edition (CE) and Enterprise Edition (EE). The releases fix 24 security vulnerabilities. One has a CVSS score of 10.0, the highest rating possible.

GitLab.com already runs the patched code. GitLab Dedicated customers don’t need to do anything. Anyone running their own instance does.

The Worst One

The critical flaw, CVE-2026-97229, is an integer overflow in the regular expression compiler GitLab uses for CI/CD. GitLab says an unauthenticated user could run arbitrary code on the GitLab server by placing a crafted regular expression in a CI/CD configuration. The root cause is weak validation of those expressions.

No login is required, and the result is remote code execution. That’s on the server holding your source code, your pipeline definitions, and, in many shops, the secrets pipelines use to reach production.

The bug affects versions 19.2 through 19.4 before the fixed releases. A researcher known as joaxcar reported it through GitLab’s HackerOne bug bounty program. The same researcher also reported a medium-severity open redirect in the Kubernetes proxy that could send authentication tokens to the wrong server.

All three releases also include patches to Ruby’s regular expression engine for Ruby 3.3 and 3.4. GitLab hasn’t said how those relate to the CVE. It makes each vulnerability’s full details public on its issue tracker 90 days after the fix.

Pipelines Are the Target

Look past the headline CVE, and a pattern emerges. Most of the high-severity fixes involve CI/CD.

• CVE-2026-16301 (CVSS 8.5) could let a Developer-role user run pipelines on protected branches through the downstream pipeline creation service.
• CVE-2026-14814 (CVSS 8.2) could let a user poison cached responses for raw repository files. Targeted users’ pipelines could then run attacker content and expose protected environment variables.
• CVE-2026-81839 (CVSS 7.7, EE only) could let a user run pipelines in a transferred project with the new group’s privileges. Old scheduled pipeline execution policy records weren’t cleaned up.

A fourth high-severity issue, CVE-2026-92883 (CVSS 8.7), is cross-site scripting in syntax highlighting. A crafted repository could run JavaScript in other users’ browser sessions.

This matters because pipelines are where code becomes running software. Protected branches, scoped tokens, and environment variables are the controls teams rely on to keep that path safe. Several of these bugs went around them.

AI Agents Get Their Own CVEs

Two fixes target the GitLab Duo Agent Platform. They deserve a closer look.

CVE-2026-96893 (CVSS 7.3) is a prompt injection issue. GitLab says an authenticated user could insert crafted content into AI agent instructions. That could trigger unintended command execution attributed to other users. GitLab team member Mert Coskuner found it internally.

CVE-2026-105458 (CVSS 4.3) could let a user with a specific granular permission get a Duo Agent Platform token that bypasses governance controls.

Both affect EE from version 19.1 on. And both show that agentic features add a new kind of attack surface inside the DevOps platform.

“Agents have turned attribution into an attack surface,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “If prompt injection can make an agent run commands logged under another developer’s name, the audit trail no longer shows who did what. Every control that relies on that trail inherits the error.”

Ashley expects that to shape buying decisions. “Agent adoption moves only as fast as teams can prove what their agents did,” he said. “Expect buyers to press DevOps vendors on how agent identity stays separate from user identity before they give agents more permissions.”

The Long Tail

The rest of the fixes are rated medium or low. But some of the bugs are old. A GitLab Pages logging issue that could expose access tokens dates back to version 12.0. An SSRF race condition in repository import goes back to 10.3. Several GraphQL authorization flaws could let unauthenticated users read confidential notes on public projects or work items from private groups.

There’s also a cluster of fine-grained personal access token bugs. Tokens scoped to a single project could modify group-level labels or group integrations. That defeats the purpose of fine-grained tokens.

A Busy Quarter for GitLab Admins

This isn’t the first urgent release in recent weeks. GitLab shipped a critical patch on August 17 for a GraphQL code injection bug. On September 10, it fixed two critical flaws: a path traversal in the commits API and insecure deserialization in GraphQL subscriptions. It later backported those fixes to 19.0 and 18.11. Another critical patch, 19.4.1, followed on September 23.

That’s four critical releases in about eight weeks. For teams that batch upgrades monthly or quarterly, that pace is a real problem. A CVSS 10 bug in the system that holds your code and secrets won’t wait for the next change window.

What to Do Now

• Upgrade self-managed instances to 19.4.2, 19.3.5, or 19.2.8.
• Plan for downtime on single-node instances. The patch includes database migrations that must finish before GitLab starts. Multi-node deployments can avoid downtime with GitLab’s zero-downtime upgrade process. Version 19.3.5 also includes post-deploy migrations.
• If you upgraded to 19.3.4, note that a bug affected merge request pages when the Ona integration was enabled. 19.3.5 fixes it.
• Review who can edit CI/CD configurations. Audit fine-grained tokens and Duo Agent Platform permissions.
• Subscribe to GitLab’s patch release RSS feed so the next one doesn’t surprise you.

If you run GitLab yourself, this patch goes to the top of today’s list.