GitLab patched a maximum-severity flaw in its CI/CD regular expression compiler three weeks ago, CISA confirmed active exploitation last week, and Shadowserver still sees over 1,000 exposed servers running the vulnerable code.

What happened

CVE-2026-97229 is an integer overflow in the regex compiler that parses expressions in pipeline configuration files. Insufficient validation means a crafted regex in a CI/CD config lets an unauthenticated user execute arbitrary code on the GitLab server. CVSS is 10.0.

GitLab fixed it in 19.2.8, 19.3.5 and 19.4.2. GitLab.com and GitLab Dedicated are already patched. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 29 October. Shadowserver separately counts over 11,300 instances still vulnerable to an earlier critical regex compiler flaw, CVE-2026-110264, which also carries a 10.0 score and affects versions from 7.0 upward.

Who is affected

Anyone running a self-managed GitLab instance that has not been upgraded since mid-October, which is the normal state of an internal instance nobody owns.

• GitLab CE and EE versions from 19.2 before 19.2.8
• Versions from 19.3 before 19.3.5
• Versions from 19.4 before 19.4.2
• Any of the above reachable from the internet, including through a reverse proxy

What to do now

Upgrade to 19.2.8, 19.3.5 or 19.4.2 on the relevant branch, then treat the instance as possibly compromised rather than merely outdated.

• Patch first, then review CI/CD configuration history for pipelines you did not author.
• Check for new admin users, personal access tokens, SSH keys and runners added since early October.
• Rotate runner registration tokens, deploy keys and any CI variables holding cloud or database credentials.
• Remove public exposure of the instance if it does not need to be internet-facing.
• If the instance predates October, go further: 19.2.9, 19.3.6 or 19.4.3 also closes CVE-2026-110264, which the 97229 builds do not.

What this means for South African businesses

Self-managed GitLab is common in local dev shops and in any business that wanted source control on its own hardware, and those instances frequently hold the deployment credentials for production. That makes this a path into customer systems, not just a code repository. My judgement: most SMEs will not patch this themselves because nobody tracks GitLab CVEs the way they track Windows, so it is worth asking your provider directly whether the instance is on 19.2.8 or later.

Source: BleepingComputer and GitLab's 19.4.2 patch release notes.

Also on the blog

• Synology C3RB3R ransomware: 380,000 exposed NAS devices, old DSM to blame
• Barracuda ESG CVE-2026-116606: 9.3 auth bypass that ends in root

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.