News / Industry
CISA flags an actively exploited GitLab flaw as organizations rush to patch
CISA added a critical GitLab flaw, CVE-2026-97229, to its Known Exploited Vulnerabilities (KEV) catalog after active exploitation. Patch GitLab CE and EE now.
On October 29, 2026, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog, confirming that a critical flaw in GitLab is being used in real attacks. The vulnerability rates CVSS 10.0, the maximum, and affects self-managed GitLab Community Edition and Enterprise Edition. It lets an unauthenticated attacker run code on the server. GitLab shipped fixed releases on October 12, and the KEV listing gave US federal agencies until November 1 to remediate. For everyone else, the catalog is a signal that the clock already started.
| Field | Detail |
|---|---|
| CVE | CVE-2026-97229 |
| Product | GitLab Community Edition and Enterprise Edition (self-managed) |
| Severity | Critical, CVSS 10.0 |
| Fixed versions | 19.2.8, 19.3.5, 19.4.2 |
| KEV status | Added October 29, 2026; remediation due November 1 |
What happened
GitLab disclosed the flaw and released patches on October 12, describing it as an integer overflow in the CI/CD regular expression compiler. Under certain conditions, it says, an unauthenticated user could run arbitrary code on a GitLab server through a specially crafted regular expression in a CI/CD configuration. The root cause was insufficient validation of that expression.
The fixed releases are 19.2.8, 19.3.5, and 19.4.2. Every version from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 is affected, in both Community Edition and Enterprise Edition. GitLab.com was already patched and GitLab Dedicated customers do not need to act, so the exposure sits with the self-managed instances that organizations run themselves.
Security firm Rapid7, which published a technical analysis and a proof of concept, reproduced code execution on an unpatched 19.4.1 server. A regular expression that passes validation in a compact US-ASCII form is recompiled by Ruby's Onigmo engine when it meets a specially formed repository path, and the overflow then yields invalid instructions that run an operating system command as the GitLab service account. Rapid7 flagged one practical condition: the attacker needs to commit a malicious CI/CD file to a branch in a public project, a bar that falls away wherever anyone can self-register and create projects.
Then the status changed. On October 29, CISA confirmed active exploitation and added the CVE to KEV. GitLab has shared threat detection guidance for self-managed customers after observing exploitation attempts, and scan data from the Shadowserver Foundation, reported by BleepingComputer, put nearly 2,800 GitLab Community Edition servers directly on the internet.
Why it matters
A source-code platform is one of the highest-value targets in a network. GitLab holds proprietary code, CI/CD pipelines, deployment credentials, and the automation tokens that reach into production. Remote code execution as the service account does not compromise a single application. It opens a path into the software supply chain behind it: build systems, artifact registries, and whatever those pipelines are trusted to deploy. That is why an unauthenticated flaw in GitLab draws attention quickly, and GitLab has shown up in the KEV catalog repeatedly since 2021.
The catalog exists to separate flaws like this from the theoretical. A KEV entry is evidence, not a forecast: CISA adds one only when it has proof the vulnerability is being used in the wild. For US federal civilian agencies, the catalog carries legal weight under Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," which requires remediation inside the timelines CISA sets. For this flaw that window was three days, with forensic triage to confirm nothing had already been breached. CISA urges organizations outside government to treat the catalog the same way: as a priority queue, not a newsletter.
A KEV listing is not a severity score. It is confirmation that someone is already using the flaw, and that is the one fact that should move a patch to the front of the line.
The Threatless read
Severity scores say how bad a flaw could be. Exploitation data says which flaws are being used right now. The two often disagree, and when they do, real exploitation should win. CVE-2026-97229 is both a CVSS 10.0 and a KEV entry, which makes it an easy call. The harder discipline is the ordinary week, when dozens of critical-rated CVEs compete for the same hours and only a handful are ever weaponized.
This is the case for prioritizing by real risk over raw score. The KEV catalog is the clearest public input into that decision, because it answers the question that matters most: is this being exploited today. Pairing that signal with your own exposure, which assets actually run GitLab, which are reachable from the internet, which sit behind authentication, is the core of continuous threat exposure management. Building security to be AI-native, so exploitation signals and exposure data land in one prioritized queue, is how that sorting keeps pace while both sides move faster. After a KEV listing, the useful question is never how severe the flaw looks on paper. It is whether you run it, and whether it is exposed.