GitLab shipped 19.4.1, 19.3.3 and 19.2.7 on September 23, 2026, closing 11 CVEs in one coordinated security release. Two of them score CVSS 9.9, GitLab's own Critical band, and both sit in the regex engine GitLab uses to parse CI/CD configuration: a crafted .gitlab-ci.yml file lets an authenticated user trigger arbitrary code execution. Three more CVEs land in the AI tooling: Duo AI, Duo Workflow and MCP each carry a separate authorization flaw, according to GitLab's patch release notes.
What GitLab patched on September 23, 2026
The release touches three branches at once. 19.4.1 is the newest minor version; 19.3.3 and 19.2.7 backport the same 11 fixes to the two prior minors, released the same day. Severity splits as two Critical, two High, five Medium and two Low.
| CVE ID | Severity | CVSS | Component | Description |
|---|---|---|---|---|
| CVE-2026-89078 | Critical | 9.9 | Regex parser (CI/CD config) | Double free enabling arbitrary code execution |
| CVE-2026-93577 | Critical | 9.9 | Regex compiler (CI/CD config) | Integer overflow enabling arbitrary code execution |
| CVE-2026-84739 | High | 8.7 | Merge request diff viewer | XSS via unsanitized path components |
| CVE-2026-92470 | High | 7.7 | Duo AI job troubleshooting | Missing authorization exposes CI/CD variables |
| CVE-2026-92874 | Medium | 5.4 | MCP API | Incorrect authorization allows token scope bypass |
| CVE-2026-92530 | Medium | 4.3 | Direct Transfer import (user mapping) | Ephemeral cache reliance during imports allows merge request author spoofing |
| CVE-2026-8937 | Medium | 4.3 | Epic Issues REST API | Missing authorization exposes private issue contents |
| CVE-2026-92529 | Medium | 4.3 | Duo Workflow | Incorrect authorization bypasses AI tool governance controls |
| CVE-2026-10518 | Medium | 4.3 | GraphQL API | Access-control flaw lets guest-level users read security policies |
| CVE-2026-4523 | Low | 3.7 | GraphQL API | Missing authorization exposes CI/CD job traces to unauthenticated users |
| CVE-2026-92628 | Low | 3.1 | MCP gitlab_search tool | Race condition causes incorrect user context |
PostgreSQL's 18.6 security release fixed 28 CVEs across five branches about six weeks earlier, another release covered in HighCircl's Platform and language release notes: what breaks and what to fix.
The two Critical vulnerabilities: double free and regex integer overflow
CVE-2026-89078 and CVE-2026-93577 both live in the same subsystem: the regex engine that parses .gitlab-ci.yml and other CI/CD configuration. One is a double free, the other an integer overflow in the regex compiler, and both end the same way, with arbitrary code execution. They sit 1.2 points above the next-highest CVE on the CVSS scale (8.7, the merge request XSS bug). GitLab's descriptions say both need only an authenticated user to trigger, so any account that can supply CI/CD configuration to the instance is worth treating as in scope.
Duo AI, Duo Workflow and MCP: three separate authorization flaws in the AI tooling
CVE-2026-92470 is a missing-authorization bug in Duo AI's job troubleshooting feature that exposes CI/CD variables. CVE-2026-92529 is an incorrect-authorization flaw in Duo Workflow that bypasses the AI tool governance controls an instance has configured. CVE-2026-92874 is an incorrect-authorization bug in the MCP API that allows a token scope bypass. That's three separate CVEs across three separate AI surfaces, each with its own root cause and its own fix.
That matters for a specific reason. Every one of these breaks the assumption that an authorization boundary set on Duo, Duo Workflow or MCP was actually being enforced. An instance running AI agents in CI, or letting Duo Workflow act on tickets and merge requests, is patched once it upgrades, but the upgrade doesn't tell you whether anything already slipped through that boundary before September 23. That makes this a review step as much as an upgrade step, and it's exactly what the how-to below covers.
How to upgrade to GitLab 19.4.1 (or 19.3.3 / 19.2.7)
1. Confirm your current version and required upgrade stops
Check your running version against GitLab's required upgrade stops for the 19.x line: 19.2, 19.5, 19.8 and 19.11. If you're already on 19.2.x or 19.3.x, going straight to 19.4.1 is valid, since the next required stop is 19.5. Anyone running a version older than 19.2 needs to land on the latest 19.2 patch first, per GitLab's upgrade path documentation. GitLab Support also publishes an upgrade path calculator that works out the exact stop sequence for a given starting version.
2. Decide if this upgrade will cause downtime
According to GitLab's zero-downtime upgrade documentation, avoiding downtime on this upgrade takes a load-balanced, multi-node deployment with HA Consul, Postgres and Redis, plus an internal load balancer in front of PgBouncer and Praefect. A single-node instance doesn't meet those conditions, so it sees downtime while the upgrade's required database migrations run. If you're on a single node, schedule a maintenance window rather than assuming this slots in unnoticed.
3. Upgrade to the latest patch of any required intermediate stop first
GitLab's upgrade path documentation says to always use the latest patch release of any required intermediate stop before moving on. If 19.2 is one of your required stops, that means landing on 19.2.7, the latest patch, rather than an earlier one like 19.2.0.
4. Let background and post-deploy migrations finish before moving on
Wait for background migrations to complete before starting the next release in your upgrade path; running two releases' migrations out of sequence can break the schema. Post-deploy migrations are available for both 19.3.3 and 19.2.7, so anyone stopping at either of those on the way to 19.4.1 has that step to run too.
5. Review Duo AI, Duo Workflow and MCP agent permissions after upgrading
Patching closes the three authorization flaws in Duo AI, Duo Workflow and MCP, but it doesn't audit what those tools were already configured to do on your instance. Once you're on a patched version, walk through the read/write default GitLab set for AI agent tools and confirm your instance's current permissions still match what you intended, since a bypassed check may have quietly allowed more than that.
If GitLab isn't the only environment on your upgrade calendar this quarter, Kubernetes 1.37's removal of 18 cAdvisor flags is worth queuing alongside it rather than discovering separately.
FAQ
Is GitLab.com affected, or only self-managed instances?
GitLab's release page addresses this directly: "GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action." The upgrade steps above apply to self-managed instances, which carry the 19.4.1, 19.3.3 and 19.2.7 version numbers and have to install the patch themselves.
Do I still need to upgrade if I don't use Duo AI or MCP?
Yes. The two Critical CVEs, the double free and the integer overflow in the regex parser, sit in CI/CD configuration parsing, unrelated to the AI tooling. Any instance that runs pipelines is exposed to those two regardless of whether Duo or MCP is enabled at all.
Will this upgrade cause downtime on my instance?
It depends on your topology. Avoiding downtime takes a load-balanced, multi-node deployment with HA Consul, Postgres and Redis, plus an internal load balancer in front of PgBouncer and Praefect. A single-node instance doesn't meet those conditions, so its required database migrations run with downtime during the upgrade.
What's the difference between 19.4.1, 19.3.3 and 19.2.7?
All three close the same 11 CVEs; the difference is which minor line each patches. 19.4.1 is the current minor, while 19.3.3 and 19.2.7 backport identical fixes for instances still on those earlier lines. GitLab's notes on the 19.3.3 and 19.2.7 backports confirm post-deploy migrations ship for both.