GitLab patches two 9.9 RCE flaws in critical release

GitLab has shipped a critical patch release fixing eleven security flaws, and two of them are as bad as they get: both carry a CVSS score of 9.9 and both let an authenticated user run their own code on the GitLab server by feeding it a crafted regular expression through a CI/CD configuration.

Two 9.9s in the same subsystem

The pair sit in the regular expression handling that CI/CD pipelines rely on. CVE-2026-89078 is a double free in the regular expression parser; CVE-2026-93577 is an integer overflow in the regular expression compiler. GitLab describes the outcome for both in the same terms: arbitrary code execution on the GitLab server. Their affected ranges are identical - GitLab CE and EE from 19.2 before 19.2.7, from 19.3 before 19.3.3, and 19.4 before 19.4.1 - and both were reported by joaxcar through GitLab's HackerOne bug bounty programme, which is a decent week of work by any standard.

The scoring parentheses are worth reading properly. Both are rated AV:N, AC:L and PR:L, which is to say the attacker only needs a low-privileged account on the instance, and both have scope changed with high confidentiality and integrity impact. On a self-managed GitLab that runs untrusted merge requests through its pipelines, a low-privileged account is exactly what an outside contributor gets.

The other nine fixes

The third serious entry is CVE-2026-84739, an 8.7-rated cross-site scripting flaw in the merge request diff viewer that lets an authenticated user run JavaScript in another user's browser session. It has been present since GitLab 13.11, so the affected range runs back years. Then comes CVE-2026-92470, a 7.7-rated missing authorization check in the Duo AI job troubleshooting feature on Enterprise Edition, which could expose sensitive CI/CD variable values from debug-mode job traces.

Below that sit four medium issues: CVE-2026-92874, where an MCP-scoped token could act outside its scope; CVE-2026-92530, where Direct Transfer imports relied on ephemeral cache state and let an authenticated user spoof merge request authorship; CVE-2026-8937, a missing authorization check in the Epic Issues REST API that exposed private child issue titles and descriptions; and an incorrect authorization flaw in the Duo Workflow Service token governance enforcement on EE. Two more low-rated fixes cover a missing authorization check in the GraphQL CI job trace API and a race condition in the MCP gitlab_search tool.

Who has to move

GitLab.com is already running the patched version and GitLab Dedicated customers need to do nothing, which leaves the self-managed installs. GitLab is blunt about those: it strongly recommends every affected installation move to 19.4.1, 19.3.3 or 19.2.7 immediately. This was not a scheduled release - those land on the second and fourth Wednesdays of the month - but an ad-hoc critical patch for high-severity vulnerabilities.

One detail administrators should notice: the issues behind each fix are published on GitLab's issue tracker 90 days after the release that patched them. Until then, the advisory gives the vulnerability class, the CVSS vector and the affected ranges, but not the exploit itself.

Our opinion

The interesting thing about this batch is not the count, it is that the two worst bugs are the same class of memory-safety error in the same subsystem, found by the same researcher, and shipped in the same patch. Regular expression engines are the one part of a modern web platform where a low-privileged user still gets to hand raw input to a C++ parser, and CI/CD pipelines are where that input is a feature rather than a bug. If you run a GitLab instance and your pipelines execute code from contributors you would not hand a shell to, this is a same-day upgrade, not a maintenance window.

The 90-day silence is the other half of the story. GitLab is right that publishing exploit details before administrators can patch would be worse, and its released ranges are precise enough to act on. But it also means most admins will upgrade without ever knowing whether someone already used a double free in a CI/CD regex against their instance, and GitLab's advisory offers no signs of exploitation to check for. Patch now, then go and look at who has been opening merge requests on your runners.