CISA Gave Agencies Until November 1 to Patch GitLab's October 12 Bug. The October 21 Bug Is Not on the List, and the October 12 Fix Does Not Cover It.
If you run self-managed GitLab and you patched to 19.4.2, 19.3.5 or 19.2.8 to meet CISA's deadline, you are still vulnerable to a second CVSS 10.0 bug. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, whichever matches your branch.
On October 29, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog with a federal due date of November 1. GitLab fixed that bug on October 12, 17 days earlier. The catalog entry links to the October 12 patch release, which is the 19.4.2 release. Nine days after that patch, on October 21, GitLab fixed a second regular expression bug, CVE-2026-110264, also CVSS 10.0. As of CISA's catalog version 2026.10.29, which we pulled today, it is not listed.
Two bugs, one deadline
We wrote the version comparison on October 22 in GitLab's Second CVSS 10 Regex Bug in Nine Days. That post said neither bug was in CISA's catalog, and that was true on October 22. One of them is now.
The ranges have not changed. GitLab's October 21 page lists CVE-2026-110264 as affecting all versions from 7.0 before 18.11.13, plus 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3 and 19.5 before 19.5.1. Every build in the October 12 release falls inside that. The deadline asks agencies to do something correct that leaves them exposed to the next bug. That is the same shape as the firewall chain we wrote about on October 28, where one half of an attack chain had a deadline and the other, when we published, did not. CISA listed that other half the same day, so a gap like this can close fast. It is open now.
We are not criticizing CISA's catalog for this. KEV lists what CISA has evidence of being exploited, and nothing we read says the second bug has been. We are pointing out that a deadline on one CVE is not a statement about the one next to it.
What we know about exploitation
Not much, and mostly from one source. Rapid7's write-up, last updated October 30, says the October 29 listing was "based on evidence of active exploitation." The KEV entry itself does not describe that exploitation. Neither GitLab's October 12 page, its October 21 page nor Ruby's advisory says whether either bug has been exploited. We have no sighting of our own.
Rapid7's analysis also changes how "unauthenticated" reads. GitLab's CVSS vector says no privileges are required. Rapid7 says an attacker must be able to commit a malicious CI/CD configuration file and a repository path containing UTF-8 characters to a branch in a public project. It says an ordinary account can satisfy that by creating a public project on an instance that allows it, and that on instances where new users can self-register and create projects, the constraint is removed. That is Rapid7's reading; GitLab's pages state no precondition. Rapid7 reports reproducing code execution as the GitLab git user on an unpatched 19.4.1 image, and no execution of that same input against 19.4.2, which is the first bug's input and says nothing about the second.
The bug family is bigger than GitLab
On October 23, Ruby published an advisory titled for the regexp fixes behind GitLab's CVEs. It maps four GitLab CVEs to three bugs in Onigmo, the regular expression engine inside Ruby: a double free, an integer overflow, and a repeat overflow. CVE-2026-97229 and CVE-2026-110264 are two of the four. Ruby says it has not requested CVE IDs of its own.
Ruby's scope statement is the part that should travel. These bugs are reached only when an application compiles a regular expression from a string an attacker controls, such as through Regexp.new or interpolation of user input. Applications that only use patterns written by their own developers are not affected. Ruby also says Regexp.timeout does not protect against these bugs, and that limiting pattern length does not reliably protect either. The fixed releases are Ruby 4.0.9, 3.4.12 and 3.3.13, and Ruby shipped 3.3.13 as an exception because GitLab had assigned CVEs to issues that rely on the fixes.
The KEV entry carries the same warning, noting that other products can potentially be affected by the same underlying Ruby and Onigmo issue and linking Ruby's advisory. We have not tested any non-GitLab product and are not naming one. If you run Ruby software that accepts patterns from users, such as search filters, rule engines, routing or custom validators, Ruby's advice is to upgrade Ruby or stop compiling untrusted input.
What we hold, and what we don't
Our exploit harvester indexed the first public proof of concept for CVE-2026-97229 on October 13, from a repository under the name of a Rapid7 researcher, and two more on October 16 and October 26. That is a third-party clock and not our detection, and the CISA listing came 16 days after the first harvest. We vouch for none of that code.
Our edge saw nothing. Using the endpoint fingerprints from those proofs of concept, we scanned 40,528 edge blocks, 25,554 edge honeypot records and 1,447 origin captures since September 30 and got zero matches. We do not run GitLab and have no GitLab canary, so that zero says almost nothing about whether anyone is scanning for it.
We have nothing to add to the feed. Rapid7 publishes no indicators of compromise, GitLab publishes detections rather than indicators, and Ruby publishes none. A repository name is not an indicator of attack. If an indicator appears, we will ingest it.
What to do
1. Find your version on the GitLab Help page, and upgrade to the fixed build for your branch: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. If you are on 18.10 or older, there is no fix on your branch, so plan an upgrade to one of those today.
2. Do not stop at 19.4.2, 19.3.5 or 19.2.8. Those satisfy the first bug and not the second.
3. Turn on GitLab's detections. The October 12 release lists six, among them "Onigmo native worker crash" and "ci regexp guard rejection," and the October 21 release lists two. Then look back through logs to October 12.
4. Reduce exposure while you plan. Rapid7 suggests restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects. It says this does not remediate the bug.
5. If you were running an exposed build, treat CI/CD variables, runner registration tokens and deploy keys as potentially exposed. Code execution on the GitLab server reaches them. The catalog entry also links CISA's forensics triage requirements.
Limits
The version ranges and dates come from GitLab's October 12 and October 21 release pages, which we read today. The exploitation statement comes from Rapid7 and we could not confirm it from CISA's entry. The Ruby details come from Ruby's own advisory. We did not test any exploit, did not independently verify that 19.4.2 is vulnerable to the second bug beyond GitLab's own affected-version text, and checked CISA's catalog on October 30, so it may have changed since.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments