If you run your own code-hosting and CI server, this one is for you. In nine days, GitLab fixed two related critical flaws in the regular-expression engine used by its CI/CD pipelines, both rated the maximum CVSS 10.0. The second release exists because the first did not close everything.
What happened
- 12 October. GitLab shipped 19.4.2, 19.3.5 and 19.2.8 for CVE-2026-97229, an integer overflow in the regex compiler used for CI/CD configuration. Weak validation of that input let an unauthenticated user run arbitrary code on the server by placing a crafted regular expression in a pipeline configuration. A researcher reported it through the bug bounty. Rapid7 reproduced code execution within a day of the release.
- 21 October. GitLab shipped 19.5.1, 19.4.3, 19.3.6 and older backports for CVE-2026-110264, another critical flaw in the regex engine that can let an unauthenticated attacker run code on a self-managed server. Servers on 19.4.2, 19.3.5 or 19.2.8, the 12 October fixes, are still affected.
As of 22 October the second flaw was not in CISA’s Known Exploited Vulnerabilities catalogue, no attacks had been reported and no public exploit had been found. That can change fast, especially after Rapid7’s quick reproduction of the first one.
Who is affected
Self-managed installations of Community and Enterprise Edition are affected, with the advisory reporting versions back to 7.0. GitLab.com and GitLab Dedicated are already patched. The same release also fixes two high-severity issues (CVE-2026-15723 and CVE-2026-112212) and several smaller ones, though the older backports carry only the critical fix.
What could happen to your systems
A code-hosting server is a very valuable target. It holds your source code, your CI secrets, deploy keys and access tokens, and it controls the runners that build and ship your software. Running code on that server is a path to all of them, and from there to your production systems and your supply chain.
What to do, in order
- Check your version (on the server,
sudo gitlab-rake gitlab:env:info, or look at the Help page as an admin). - Upgrade to the fixed release for your branch, using the list in the figure. If you are on 18.10 or older there is no fixed release for your branch; move to a supported line, following GitLab’s upgrade path rules so you do not skip required stops.
- Back up first, and read the release notes: some of the fixed releases include database migrations.
- Reduce exposure until you finish. Put the server behind a VPN or allowlist, disable public sign-up, and review who can edit pipeline configuration.
- Look for trouble. Check the audit log and recent pipelines for unfamiliar projects, odd CI configuration changes, new runners, new tokens or deploy keys, and unexpected outbound connections from the server.
- If you find anything, rotate secrets: CI variables, runner tokens, deploy keys, personal and project access tokens, and any credentials stored in the instance.
- Subscribe to the security-release feed so a “second fix” does not slip past you.
Sources and honesty
This summary relies on DevOps.com’s report on the 12 October release and Konfirmity’s advisory summary of the 21 October one. We could not open GitLab’s own release notes, so please confirm version numbers there before you act.