> ## Content Index > Fetch the complete content index at: https://stackurity.ai/blog/llms.txt > Use this file to discover other available public pages before exploring further. # GitLab CVE-2026-97229: exploited critical flaw, how to fix it - URL: https://stackurity.ai/blog/gitlab-cve-2026-97229-exploited-regex-rce/ - Published: 2026-10-30T02:05:03.000Z - Updated: 2026-10-30T12:23:02.000Z - Description: CVE-2026-97229 is an exploited, critical GitLab flaw that allows remote code execution. See affected versions, how to check a server and how to upgrade. - Author: Stackurity Research Team - Tags: Actively Exploited, #deep-dive ## TL;DR - **What:** an integer overflow or wraparound flaw (CWE-190) in GitLab Community Edition and Enterprise Edition, tracked as CVE-2026-97229, in how GitLab handles a regular expression supplied through pipeline settings. - **Impact:** an unauthenticated attacker could run arbitrary code on the GitLab server. - **Severity:** a CVSS v3.1 score of 10 from GitLab, rated critical. - **Exploited:** yes, CISA added it to its Known Exploited Vulnerabilities catalogue on October 29, 2026, with a due date of November 1, 2026 for federal agencies. - **Fix:** upgrade to GitLab 19.2.8, 19.3.5 or 19.4.2, whichever matches your line, or to a newer release. ## What the vulnerability is GitLab is a platform for hosting source code and running CI/CD pipelines. Pipelines are described in a configuration file, and that file can contain regular expressions, which are small patterns used to match text such as branch names or job output. GitLab has to read and compile those patterns before it can use them. The flaw sits in that step. The National Vulnerability Database describes it as insufficient validation of a regular expression, and classifies the weakness as an integer overflow or wraparound (CWE-190). In plain terms, a specially built pattern can make the regular expression compiler do arithmetic that overflows, and that can end with the attacker running code of their choosing on the GitLab server. According to the description, no login is needed. The attacker only has to get a malicious pattern into pipeline settings that GitLab processes. GitLab scored the issue itself, with a CVSS v3.1 base score of 10 and the vector showing a network attack, low complexity, no privileges and no user interaction. That is the top of the scale. ## Why it matters now Two facts make this urgent. First, it is confirmed as exploited: CISA put it in the Known Exploited Vulnerabilities catalogue on October 29, 2026 and set a due date of November 1, 2026\. That is a very short window, which tells you how seriously CISA rates it. Second, a GitLab server is a high value target. It holds source code, build secrets and deployment credentials, so code execution on it can be a way into everything it touches. CISA also adds a note that matters beyond GitLab: the weak spot is in the regular expression compiler of Ruby, so software outside GitLab might share the problem. If you run other software built on the same compiler, watch for advisories from those vendors as well. The NVD entry was published on October 13, 2026 and is still marked as undergoing analysis, so it may still change. The description already gives the affected releases and the vendor has published the fixed ones, so you can act today without waiting for the record to be completed. ## Am I affected? The affected releases are GitLab from 19.2.0 up to 19.2.8 (not including 19.2.8), from 19.3.0 up to 19.3.5 (not including 19.3.5), and from 19.4.0 up to 19.4.2 (not including 19.4.2). The fixed releases are therefore 19.2.8, 19.3.5 and 19.4.2\. The description does not say whether releases older than 19.2 are affected, so check GitLab's patch release notes rather than assuming an old install is safe. To check one Linux machine by hand, look at the installed package and, if you can, at the running application: ``` dpkg -l | grep -i gitlab rpm -qa | grep -i gitlab gitlab-rake gitlab:env:info ``` Use the line that matches your package manager. Remember that GitLab can also run in a container image, so check the image tag of any GitLab container as well, and look for runner or helper hosts that carry their own copy. **Backport caveat:** some Linux distributions patch a security flaw in place and keep the old version number. GitLab itself is normally installed from the vendor's own packages, where the version number is the reliable signal. If your GitLab comes from a distribution or another third party, read that source's security notice before you decide whether a machine is exposed. ## How to fix CVE-2026-97229 1. Find every GitLab Community Edition and Enterprise Edition instance you run, including test servers and container images, and note its release. 2. Upgrade each instance to the fixed release in its line: 19.2.8, 19.3.5 or 19.4.2, or to a newer release. GitLab's [patch release notes](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/) list the changes. 3. Restart the services after the upgrade so the new code is the code that runs, and rebuild container images from the fixed release rather than patching running containers. 4. Because the flaw is exploited, review the server for signs of compromise from before the patch, in line with the forensic triage guidance that CISA links from its entry. Rotate secrets stored in or reachable from the server if you find anything. 5. If you cannot upgrade at once, follow GitLab's mitigation instructions, as CISA's required action says, and restrict who can reach the server and who can change CI/CD configuration until you can. The vendor notes also point to a Ruby release that fixes the regular expression problem for other users of the same compiler, so check any other Ruby software you operate. ## How to check with Stackurity The hard part of a flaw like this is knowing every place GitLab runs. Stackurity keeps one live inventory of the software on your servers, deployed applications, repositories, container images, Kubernetes workloads and AWS managed services. A read-only agent on Linux servers reads installed packages, runtimes installed by hand and the libraries that deployed applications actually load, so a GitLab install on a server or inside an image shows up in the same list. Stackurity matches that inventory every hour against new advisories and every day against the CISA Known Exploited Vulnerabilities catalogue, using each ecosystem's own version rules. Each finding is ranked from exploitation, exposure and environment, and says in one sentence why it applies. A known exploited flaw like this one ranks high, and the fix is one card with the version to move to. See [how fixes are tracked](https://stackurity.ai/docs/remediation) for the details. After you upgrade, the check again step asks the agent for a fresh report and records whether the issue is passed, partly fixed or still open, so you can show the fix is real; [the verification guide](https://stackurity.ai/docs/verification) explains it. Stackurity has limits: it does not cover network appliance firmware, or libraries copied into an application outside a package manager. The Community edition is free and self-hosted, and Stackurity Cloud has a [14-day free trial without a card](https://app.stackurity.dev/signup?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=actively-exploited&utm%5Fcontent=gitlab-cve-2026-97229-exploited-regex-rce). For other exploited flaws that need the same kind of search across servers, see our posts on [the Adobe Commerce and Magento flaw](https://stackurity.ai/blog/adobe-commerce-magento-cve-2026-48356-exploited/) and [the ProFTPD mod\_copy flaw](https://stackurity.ai/blog/proftpd-cve-2015-3306-exploited-mod-copy-flaw/). ## FAQ ### Is CVE-2026-97229 being exploited? Yes. CISA added it to its Known Exploited Vulnerabilities catalogue on October 29, 2026, with a due date of November 1, 2026 for federal agencies. CISA lists known ransomware campaign use as unknown. ### Which GitLab versions are fixed? The fixed releases are 19.2.8, 19.3.5 and 19.4.2\. Each earlier release in the 19.2, 19.3 and 19.4 lines is affected, so move to the fixed release in your line or a newer one. ### Do I need to be logged in to exploit it? No. The description says an unauthenticated user could run arbitrary code on the GitLab server by getting a malicious pattern into a pipeline configuration. ### Can a distribution package fix this without changing the version number? Yes, distributions sometimes backport a fix and keep the old version string. For GitLab, compare your installed version with the fixed releases in the vendor patch notes, and read your package source's notice if it ships its own build. ### How does Stackurity help with this? Stackurity keeps one inventory of the software on your servers and container images, matches it every hour against vulnerability data and every day against the CISA catalogue, and checks again after the fix to record whether the issue is gone. Sources: [CISA Known Exploited Vulnerabilities catalogue](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search%5Fapi%5Ffulltext=CVE-2026-97229), [NIST National Vulnerability Database](https://nvd.nist.gov/vuln/detail/CVE-2026-97229) and [Stackurity product facts](https://stackurity.ai/llms.txt).