CISA put GitLab CVE-2026-97229 on its Known Exploited Vulnerabilities list on October 29, 2026. The flaw carries the maximum CVSS score of 10.0, and per Rapid7’s technical write-up, it lets an attacker run code on a self-managed GitLab server with no login at all, provided the instance allows self-registration and public projects. Federal civilian agencies have until November 1 to deal with it. That is tomorrow.
The twist that makes this more than another critical patch story: updating GitLab may not be enough. The bug lives in Ruby’s regex engine, so a server can run a “fixed” GitLab release and still carry the vulnerable Ruby underneath. Alpine Linux learned that the hard way this month, and its experience is the clearest evidence yet of what a GitLab vulnerability of this type does to a real project.
It is also another GitLab flaw with a perfect 10.0 score to reach attackers’ hands since September, after CVE-2026-85706. Below we cover how the bug works, who is exposed, what the Alpine incident showed, how to check your own Ruby runtime, and where we think the next few weeks go.
GitLab CVE-2026-97229 at a Glance
- Severity: CVSS 10.0, unauthenticated remote code execution on self-managed GitLab Community and Enterprise Editions.
- Root cause: an integer overflow in the way regular expressions in CI/CD configuration files get compiled. The faulty code sits in Onigmo, the regex engine built into Ruby.
- Fixed GitLab releases: 19.2.8, 19.3.5 and 19.4.2, all shipped October 12, 2026.
- CISA KEV listing: October 29, 2026, with a November 1 remediation date for federal agencies.
- Known attack: Alpine Linux’s public GitLab took eight worker crashes over October 20 and 21 and was rebuilt from scratch on October 27 and 28.
- Catch: the fix is a set of patches to the Ruby interpreter bundled with GitLab, so custom Ruby builds need a separate upgrade.
What Happened Between October 12 and October 29
GitLab released patches on October 12 for three supported branches. Rapid7 published its analysis the next day, October 13, and said it had reproduced code execution on GitLab 19.4.1 Community Edition. Censys issued an advisory the same day and listed a public proof of concept from Rapid7. At that point, Censys noted no reports of exploitation in the wild and no KEV entry.
That changed within a week. On October 20, someone registered an account on Alpine Linux’s public GitLab and began sending crafted CI configurations. CISA’s KEV addition followed on October 29, which means the agency saw evidence of exploitation it considered reliable. The gap between patch and listing was 17 days, long enough for a motivated attacker to weaponize a public proof of concept and short enough that many teams had not finished their patch cycles.
| Date (2026) | Event |
|---|---|
| October 12 | GitLab ships 19.2.8, 19.3.5 and 19.4.2 |
| October 13 | Rapid7 publishes analysis and reproduces RCE on 19.4.1 CE, Censys issues advisory |
| October 13 | Alpine upgrades its instance to 19.3.4, one patch short of the fixed 19.3.5 |
| October 20 to 21 | Attacker crashes Alpine’s GitLab workers eight times |
| October 22 | Alpine moves to 19.3.6, still on an unpatched Ruby |
| October 22 to 23 | Upstream Ruby releases 3.3.13, 3.4.12 and 4.0.9 |
| October 27 to 28 | Alpine closes and rebuilds the instance from scratch |
| October 29 | CISA adds CVE-2026-97229 to the KEV catalog |
| November 1 | Federal remediation date under BOD 26-04 |
How the Regex Bug Becomes Code Execution
According to Rapid7, the flaw is an integer overflow in the program-size calculation inside Onigmo. A CI/CD configuration containing specially crafted UTF-8 repository paths forces the regex to recompile after validation checks have already passed. The recompile produces invalid instructions and corrupts control flow in the Ruby process that GitLab uses to evaluate the configuration.
The attacker’s job is simple on paper. Commit a malicious .gitlab-ci.yml to a public repository, using UTF-8 characters in the path, and let GitLab parse it. On an instance that allows open self-registration and public project creation, Rapid7 describes the chain as fully unauthenticated. Anyone on the internet can create the account, create the project and trigger the parse.
Why a “Regex Bug” Is a Remote Code Execution Bug
Regex engines compile patterns into small bytecode programs. If the size of that program gets miscalculated, the engine can write past the buffer it allocated. That is classic memory corruption, and memory corruption in an interpreter that parses attacker-controlled input tends to end in code execution. The Alpine logs fit this picture: workers crashed repeatedly as the attacker tuned the payload.
Who Is Exposed: Versions and Branches
The affected range covers the three newest GitLab branches. GitLab.com was already patched before disclosure, according to Censys, so the exposure sits with self-managed Community and Enterprise Edition installs. Our table uses the version ranges that both Rapid7 and Censys list.
| Branch | Vulnerable releases | Fixed release |
|---|---|---|
| 19.2 | 19.2.0 through 19.2.7 | 19.2.8 |
| 19.3 | 19.3.0 through 19.3.4 | 19.3.5 |
| 19.4 | 19.4.0 through 19.4.1 | 19.4.2 |
One outlet’s summary gives a slightly different cutoff for the 19.3 branch, so treat 19.3.5 as the safe floor, the figure both the Rapid7 and Censys advisories use. If you run anything older than the 19.2 branch, you are outside the supported fix window and should plan a jump to a current branch rather than a point release.
How Many Servers Sit on the Open Internet
Censys counted 25,766 vulnerable hosts and 79,224 vulnerable web properties when it published its October 13 advisory. The two numbers differ because one host can serve several web properties. Those figures predate most patching, so the live total today is almost certainly lower. They still give a sense of scale: tens of thousands of build servers that hold source code, pipeline secrets and deployment credentials were reachable before the first fix was applied.
A GitLab server is a high-value target because compromise rarely stays on one box. Repositories, CI variables and runner tokens give an intruder a path into production. We saw the same logic in the JetBrains TeamCity attacks, where a build server flaw with a 9.8 score drew ransomware operators. Build infrastructure keeps landing on attacker shopping lists for a reason.
The Alpine Linux Incident
Alpine’s account of the attack is the most detailed public data point we have, and it reads like a case study. Someone registered a new account on October 20 and started feeding the instance crafted CI files. The workers crashed eight times across October 20 and 21. According to Alpine, four of those attempts got past the initial regex crash and failed only at the next stage. The attacker also pulled Alpine’s GitLab container image, which suggests the exploit was being tuned to that exact build.
Alpine could not prove the code execution had failed. Background job logs and the old container filesystem were gone, so the team treated the server as compromised. It closed the instance on October 27 and 28, rebuilt it from scratch and reset passwords and secret keys. Per a StartupHub summary of the report, the team also verified commits from October 20 to 22 and packages built from October 20 to 24, and reported no confirmed tampering with packages.
The Patch That Did Not Patch
Alpine upgraded to 19.3.4 on October 13, a release short of the fixed 19.3.5. It moved to 19.3.6 on October 22, and the instance stayed exploitable because the image shipped a standard Ruby without the fix. The team republished 19.3.6 with Ruby 3.3.13 on October 27. A version string told Alpine’s admins one story and the Ruby runtime told another.
Why Updating GitLab Alone May Not Close the Hole
The DEV Community analysis puts it plainly: the vulnerability lives in Onigmo, not in GitLab’s own code. GitLab’s remedy is a set of patches applied to the Ruby interpreter that it bundles in its packages and container images. Upstream Ruby shipped fixes in 3.3.13, 3.4.12 and 4.0.9 on October 22 and 23. Ruby 3.2 is end-of-life and, per one report, will not get a fix.
That creates three groups of operators:
- Official GitLab packages and images: upgrading to 19.2.8, 19.3.5, 19.4.2 or later brings the patched bundled Ruby along.
- Custom Ruby builds or derived images: you must upgrade Ruby yourself to 3.3.13, 3.4.12 or 4.0.9 or newer.
- Anyone on Ruby 3.2: no upstream fix is planned, so the only route is a newer Ruby or the vendor’s patched bundle.
For Omnibus installs, the bundled interpreter is easy to inspect. For containers, query the runtime inside the running image rather than trusting the tag.
# Omnibus install: show the bundled Ruby
/opt/gitlab/embedded/bin/ruby -v
# Summary of GitLab and Ruby versions
sudo gitlab-rake gitlab:env:info
# Container: query the runtime in the running image
docker exec <container> ruby -vA word of caution on that check. A vendor can backport a fix without changing the upstream version number, so a Ruby string below 3.3.13 on an official GitLab package does not prove exposure. Confirm against GitLab’s release notes for the exact package you run.
CISA’s KEV Listing and the Federal Clock
Under Binding Operational Directive 26-04, federal civilian agencies must prioritize KEV entries on exposed assets, and for this listing the remediation date is November 1. PBX Science’s coverage reports the same date and adds that agencies should also run forensic triage for signs of compromise before the update. A three-day window is tight. We covered how CISA applied the same pressure when ransomware crews hit a VMware bug and agencies got just three days.
Private companies do not answer to BOD 26-04, but they should read the KEV as a signal. A listing means someone has already used the flaw against a real target. Teams that need a repeatable process can follow our 12-step KEV patch workflow, and those weighing score types will find the trade-offs in our comparison of EPSS, CVSS, KEV and SSVC. For CVE-2026-97229, every one of those frameworks points the same way: patch now.
| KEV addition (2026) | Product | CVE |
|---|---|---|
| October 14 | Palo Alto Networks PAN-OS | CVE-2026-0322 |
| October 14 | Cisco Secure Email Gateway | CVE-2026-76519 |
| October 14 | Ahsay AhsayCBS (two entries) | CVE-2026-105133, CVE-2026-105134 |
| October 28 | Broadcom VMware ESX | CVE-2026-41709 |
| October 28 | Linux kernel | CVE-2026-46300 |
| October 29 | GitLab CE and EE | CVE-2026-97229 |
| October 29 | Cisco Secure Firewall ASA and FTD | CVE-2026-76418 |
A Second CVSS 10.0 Flaw Is Already Behind It
Operators who patched to 19.2.8, 19.3.5 or 19.4.2 are not finished. Two outlets report a separate GitLab regex flaw, CVE-2026-110264, that also scores 10.0. According to PBX Science, it requires administrators to move to 19.4.3, 19.3.6 or 19.2.9, or to a newer branch. The details are thinner than for CVE-2026-97229, so check GitLab’s own advisory before you plan a window. The practical lesson is to schedule one upgrade to the latest point release on your branch instead of stopping at the minimum fix for the first CVE.
GitLab’s Rough 2026 and How It Compares
GitLab has had a hard year on the security front. In September we covered a CVSS 9.4 bug exploited within 48 hours of a patch. In early October, GitLab fixed a CVSS 9.9 AI Gateway remote code execution flaw in its Duo Agent. Add the earlier 10.0 flaw and this one, and the platform has logged four serious entries in roughly two months.
GitLab is not alone. The JetBrains TeamCity case and a run of perimeter zero-days have shown that attackers target any system that holds credentials for everything else. Where GitLab differs is that its newest flaw sits in a dependency. Supply chains of that kind raise a hard question for every self-hosting team: who owns the patch for the library under your tool?
Market and Business Impact
We have no reliable data on stock moves or customer churn tied to this flaw, so we will not guess. The commercial effect is easier to describe in qualitative terms. Self-hosted GitLab buyers choose it for control, often in regulated sectors. A flaw that reaches the build system forces those buyers to explain exposure to auditors and, in some cases, to rotate every secret the server ever held.
Security vendors gain from the episode. Exposure scanners and vulnerability management platforms sell on the promise that they surface exactly this kind of mismatch between a version string and a runtime. Rapid7 said a vulnerability check shipped in its October 13 content release, which means customers with scanning in place knew about their exposure within a day of disclosure.
What to Do Today: A Practical Checklist
- Inventory. List every self-managed GitLab instance, including forgotten test servers and runner hosts.
- Upgrade. Move to 19.2.8, 19.3.5 or 19.4.2 at minimum, and ideally to the newest point release on your branch to cover CVE-2026-110264.
- Verify Ruby. Check the runtime in the running image or package and confirm it carries the fix. Do not stop at the GitLab version.
- Restrict exposure. Per Rapid7, limiting anonymous access to public projects and blocking untrusted users from creating or writing public projects helps, but it does not replace patching. Censys also advises restricting inbound access to the web interface when you cannot upgrade immediately.
- Hunt for compromise. Look for repeated worker crashes during CI parsing, unexpected child processes spawned by GitLab workers and SSH keys nobody can account for.
- Rotate secrets. If the instance was exposed and unpatched after October 12, treat CI variables, runner tokens and deploy keys as potentially compromised, as Alpine did.
Five Predictions for the Next 30 Days
- More victims surface. Alpine published its incident because it noticed. Quiet compromises on less-monitored servers usually come out weeks later, so expect more disclosures.
- Ruby dependency audits become routine. Teams that self-host tools built on Ruby will start checking the interpreter, not just the application version.
- Scanners add runtime-aware checks. Vendors will ship detections that read the actual Ruby build inside containers.
- Ransomware crews adopt the exploit. Public proof-of-concept code plus tens of thousands of exposed hosts is a pattern ransomware affiliates have exploited before, as the TeamCity case showed.
- Regex engines draw researcher attention. A flaw this severe in Onigmo will push researchers to examine other places where untrusted patterns get compiled.
These are our assessments, not confirmed events. The first and fourth are the most likely given how the Alpine case unfolded and how attackers treated earlier build-server bugs.
Where This Leaves Self-Hosted DevOps
The takeaway: a patched application on an unpatched dependency is not a patched system. Security work for the rest of 2026 will keep shifting from “which version are we on?” to “what is actually running?” For more reporting on exploited flaws and the teams racing to fix them, see our cybersecurity coverage.
Frequently Asked Questions
What is CVE-2026-97229?
It is a CVSS 10.0 integer overflow in the way GitLab compiles regular expressions found in CI/CD configuration files. The bug sits in Onigmo, the regex engine inside Ruby, and allows unauthenticated remote code execution on self-managed GitLab Community and Enterprise Editions.
Which GitLab versions are affected?
Releases 19.2.0 through 19.2.7, 19.3.0 through 19.3.4 and 19.4.0 through 19.4.1. The fixed releases are 19.2.8, 19.3.5 and 19.4.2. GitLab.com was patched before disclosure.
Is it being exploited?
Yes. CISA added it to the KEV catalog on October 29, 2026, and Alpine Linux reported attempts against its public GitLab on October 20 and 21, including eight worker crashes.
Why might a patched server still be vulnerable?
The flaw lives in Ruby’s regex engine. GitLab’s fix patches the Ruby interpreter bundled in its packages and images, so custom Ruby builds or derived images need Ruby 3.3.13, 3.4.12 or 4.0.9 or newer. Alpine’s instance stayed exposed after upgrading GitLab for that reason.
What is the federal deadline?
Federal civilian agencies must remediate by November 1, 2026 under BOD 26-04, according to PBX Science and CyberSecurityNews coverage of the KEV listing.
Can I mitigate without upgrading?
Only partly. Rapid7 lists restricting anonymous access to public projects and preventing untrusted users from creating or writing public projects, and notes these controls are not sufficient alone. Censys advises limiting inbound access to the GitLab web interface. Patching remains the fix.
Is there a second critical GitLab flaw to patch?
Reports describe CVE-2026-110264, another CVSS 10.0 regex flaw, with fixes in 19.4.3, 19.3.6 and 19.2.9 or newer branches. Verify the details in GitLab’s advisory and upgrade to the latest point release on your branch.