CISA lists GitLab CVE-2026-97229 as exploited: three days and forensic triage for federal agencies
CISA added GitLab CVE-2026-97229, an unauthenticated code execution flaw via a crafted regular expression, to its Known Exploited Vulnerabilities catalogue on 29 October 2026. Federal agencies get three days and a forensic triage duty; the entry names no attacker, date or victim count.
By Parminder Kumar Sharma · LinkedIn · · 18 min read
A three day clock that ends on a Sunday
CISA's Known Exploited Vulnerabilities file, catalogue version 2026.10.29, released at 19:09 UTC on 29 October 2026, lists GitLab CVE-2026-97229 with dateAdded 2026-10-29 and dueDate 2026-11-01. That is three days (derived), and 1 November 2026 is a Sunday (derived). The same entry carries forensicTriage: Yes, so the three days cover more than a patch: the entry points at CISA's forensic triage requirements as well. GitLab published the fixed releases on 12 October, which is 17 days before the listing (derived). A Cisco firewall flaw, CVE-2026-76418, was added the same day with the same due date and forensicTriage: No; it is a separate story and is not covered here.
What the listing does not establish: it does not say who exploited the flaw, when exploitation began, how many GitLab servers were hit, or how. The entry sets knownRansomwareCampaignUse to Unknown. GitLab's own advisory, read in full, does not say the flaw is exploited at all. CISA's statement that exploitation is happening is the only primary statement of it that this briefing could read, and it comes without detail.
Primary sources read, in full, between 21:09 and 21:21 GMT on Thursday 29 October 2026: the KEV file and the catalogue page; CISA's BOD 26-04, its implementation guidance and the revoked BOD 22-01; GitLab's 19.4.2 patch release page and its later 19.5.1 page; the CVE record and the NVD record; and Ruby's note on the engine bugs behind the GitLab CVEs. One secondary source, Daily Security Review of 14 October, is used only for what was reported before the listing and is labelled as secondary where it appears. An earlier briefing, GitLab says CVE-2026-97229 needs no account, was written before CISA's listing; this one starts where it stopped.
One interest to state. GitLab sells hosted and self managed subscriptions and wrote the advisory, the CVE record and the severity score; every figure that comes from GitLab is GitLab's own. CISA is a US federal agency and the listing is its judgement, with the evidence behind it not published in the entry.
What the KEV entry says, field by field
The table reads each field of the entry as printed in the KEV file and sets beside it what that field leaves open. The names and values in the middle column are CISA's words.
CISA KEV entry for CVE-2026-97229, read from the KEV file on 29 October 2026 at 21:09 GMT; the right column is what the field does not say.
| Field | Printed in the entry | Not stated |
|---|---|---|
| vulnerabilityName | GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability | Nothing about regular expressions or CI/CD in the name; the generic weakness name is CWE-190's |
| shortDescription | An unauthenticated user could execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration | Whether any real attack was unauthenticated in practice, and which instances |
| dateAdded and dueDate | 2026-10-29 and 2026-11-01 | Which agencies run the product, and the date exploitation began |
| requiredAction | Apply mitigations in accordance with vendor instructions, with BOD 26-04 and the Forensics Triage Requirements; discontinue use if mitigations are unavailable | Any mitigation: GitLab's page names an upgrade and no workaround |
| knownRansomwareCampaignUse | Unknown | Any actor, motive or campaign |
| forensicTriage | Yes | Entry specific triage steps or indicators of compromise |
| notes | Other products can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue; links to Ruby, GitLab, BOD 26-04, the triage requirements and NVD | Which other products, and whether they are exploited |
| cwes | CWE-190 | Anything about the exploit path |
Two details matter. The requiredAction text tells agencies to apply mitigations in accordance with vendor instructions, and the vendor's page prints a fix and six detections but no workaround. And the notes field says other products can potentially be affected by the same Ruby and Onigmo issue, which moves the story from one vendor to the regular expression engine many Ruby applications use.
What GitLab and the CVE record say, and what they leave out
GitLab's patch release page is headed Critical Patch Release 19.4.2, 19.3.5, 19.2.8 and says the versions were released on 12 October 2026. It describes the flaw as an issue that, "under certain conditions", could have allowed an unauthenticated user to run arbitrary code on the GitLab server through a crafted regular expression in a CI/CD configuration. It scores it CVSS 10.0 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and lists the affected versions as 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. The CVE record, published 13 October, repeats those versions and says to upgrade to 19.2.8, 19.3.5, 19.4.2 or above.
The page also says that 19.3.4 had a bug that affected merge request pages when the Ona integration was enabled, fixed in 19.3.5. That is why the fixed version on the 19.3 line is 19.3.5 and not 19.3.4. GitLab.com was already patched, and GitLab Dedicated tenants were patched with an internal release before the public one. A researcher outside the company reported the flaw through GitLab's bug bounty programme on HackerOne.
GitLab's 19.4.2 patch page and the CVE record, read 29 October 2026; derived items are marked.
| Question | What the vendor record says | Not stated or derived |
|---|---|---|
| Is it exploited? | Nothing on the page; the only mention of exploitation is a heading for six threat detections | Not stated by GitLab at all |
| Is there a workaround? | The recommended action is to upgrade; no mitigation line is printed | Not stated |
| When are the details public? | Issues for security fixes are made public 90 days after the release | 10 January 2027 for the 12 October release (derived) |
| Does the NVD agree? | NVD status Undergoing Analysis at the time of reading; the only CVSS score shown is GitLab's own 10.0 | NVD had not yet added the KEV fields when read |
| Which versions are safe? | 19.2.8, 19.3.5, 19.4.2 or above for this CVE | A later CVE changes the answer, see the section on the second regular expression flaw |
That last row is the practical point. The fixed versions in the KEV notes link are the ones GitLab shipped on 12 October. They are not the newest, and the next section explains why that matters.
Who says it is exploited, and what that is worth
Two CISA records carry the statement. The KEV entry exists, which on CISA's own implementation guidance means CISA found reliable evidence of active exploitation in the wild, a clear mitigation and significant risk to US government systems. And the CVE record carries CISA's enrichment, timestamped 29 October 2026 at 19:50 UTC: Exploitation active, Automatable yes, Technical Impact total. Three of the four inputs to the directive's Table 1 are KEV status, Automatable and Technical Impact, and CISA supplies all three.
How CISA decides is described on the same page: it relies on security vendors, researchers, US and international government partners, open source research and commercial threat intelligence, reviews the evidence, and adds only verifiable information. The page also warns that a listing does not necessarily mean CISA is currently observing exploitation. None of that evidence is attached to the entry, so a reader cannot test it.
What each source says about exploitation of CVE-2026-97229, read 29 October 2026.
| Source | What it says | What it does not say |
|---|---|---|
| CISA KEV entry and enrichment, 29 October | Exploitation is active | Who, when it began, how many instances, whether through the public exploit, any indicators |
| GitLab advisory, 12 October | Fix, versions, CVSS 10.0, six detections | That exploitation occurred; any workaround |
| Daily Security Review, 14 October (secondary) | Reports a proof of concept from a security firm on 13 October, a count of 25,766 exposed hosts from a scanning firm, and no confirmed exploitation | Primary pages for those two claims were not read here; the report predates the listing by 15 days (derived) |
Read in order, the record says that on 14 October a secondary report found no confirmed exploitation, and on 29 October CISA states there is some. What changed in between is not published. The listing is also not the first for GitLab: the same file shows CVE-2026-85706 added on 11 September 2026 with forensicTriage Yes, 48 days before this one (derived).
What BOD 26-04 changes compared with BOD 22-01
BOD 26-04 is dated 10 June 2026 and states that it supersedes and revokes BOD 19-02 and BOD 22-01. The comparison below uses only what each page prints.
BOD 22-01 (revoked page) and BOD 26-04 and its implementation guidance, read 29 October 2026.
| Point | BOD 22-01, as written | BOD 26-04, as written |
|---|---|---|
| Timeline rule | Six months for CVE ids assigned before 2021, two weeks for all others, adjustable in grave risk | A 16 row table: three days, 14 days, 60 days or fix on system upgrade, from exposure, KEV status, automatable and technical impact |
| Forensics | No triage requirement on the page | Three days and forensic triage on rows 1, 3 and 9 of the table |
| Who is bound | Federal information systems on agency premises or hosted by third parties on an agency's behalf | Federal Civilian Executive Branch agencies; contractors only if the contract says so; FedRAMP offerings through the FedRAMP office |
| Severity labels | FAQ says CVSS can still be part of an organisation's own efforts; BOD 19-02 separately covered critical and high flaws on internet facing systems | Revokes both; FAQ says federal agencies no longer need CVSS for prioritisation |
| Phasing | Procedures updated within 60 days | Phase I at once, Phase II within 60 days, Phase III within 180 days of 10 June (7 December 2026, derived) |
| Waivers | Not addressed on the page | FAQ says CISA does not issue waivers or exceptions |
Applying the table: CISA's enrichment gives Automatable yes and Technical Impact total, and the CVE is in the KEV. The only open input is whether the asset is publicly exposed, which the agency decides asset by asset. Row 1 (exposed) and row 9 (not exposed) both say three days and forensic triage, so exposure does not soften the answer for this CVE. That reading is this site's, derived from the table and the enrichment, not a CISA statement about GitLab.
Two cautions against over reading the change. First, three days is not new in the file itself: entries added in late May, before the directive, already carry three day due dates, so the figure did not appear with BOD 26-04. What the directive adds is the table that produces the date and the triage duty attached to some rows. Second, of the 147 entries in the file added on or after 10 June 2026, 95 carry forensicTriage Yes, 23 have three days without it and 29 have 14 days (all derived from the file as read). Three days and triage is now the common outcome, not an exception.
How the 180 day phase and the dates in the file fit together is a question the pages do not settle. The directive puts the table's timelines in Phase III, within 180 days of issuance, while the implementation FAQ says agencies should remediate by the dueDate in the KEV and that CISA computes it from the table. This briefing reports both and does not resolve them.
Who is bound, and who is not. The directive compels federal civilian executive branch agencies; it excludes national security systems and certain Department of War and intelligence community systems. Everyone else is not ordered by it. The catalogue page tells organisations in general to use the KEV as an input to their own prioritisation. A private company running GitLab has no due date from CISA, and the sensible reading is that it has the same flaw and a shorter window than usual.
Forensic triage as CISA prints it
The entry's requiredAction names CISA's Forensics Triage Requirements, and the notes link them to the implementation guidance page. That page sets out six steps and says they are baseline guidance, with entry specific steps taking precedence where the KEV prints them. It also says the target times are recommended best practice: the requirement is that an adequate forensic triage is performed, not that these times are met.
The order is the point. Step 2 says to collect volatile data first and, where possible, not to alter or remediate systems before collecting evidence. Step 3, patching, comes after, with the warning that patching may destroy artifacts. Step 4 says containment must not alert the threat actor. Step 6 asks for a written report that ends in one of three findings: no evidence of compromise, compromise confirmed or compromise suspected. The three day due date has to hold all of that.
What the entry does not give is the artifact list. CISA's guidance says that whenever it has indicators of compromise or specific forensic guidance for a listing, it will add them to the entry. The notes for CVE-2026-97229 contain links and no indicators or steps. The nearest thing to a hunt list is GitLab's: it says its security team released six threat detections for self managed customers, and names them (see the technical details).
The fixed version in the listing is not the newest, and a second flaw followed
On 21 October 2026, nine days after the 12 October release, GitLab shipped another critical patch release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. It fixes CVE-2026-110264, another integer overflow in the Regular Expression Compiler, which GitLab also rates CVSS 10.0 with the same unauthenticated vector. Its affected range is wider: all versions from 7.0 before 18.11.13, 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. GitLab says it backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9. The newest patch release in GitLab's feed at the time of reading was that 21 October one.
Ruby explains why these keep coming. In its 23 October note the Ruby project says GitLab compiles regular expressions supplied by its users, such as patterns in CI configuration, with Regexp.new, and that crafted patterns could corrupt memory while Ruby compiles them. It released Ruby 4.0.9, 3.4.12 and 3.3.13 with the fixes, says applications that only use patterns their own developers wrote are not affected, and says Regexp.timeout does not protect against these bugs and that limiting pattern length does not reliably protect either. Ruby also says it has not requested CVE identifiers for these fixes, at least for now. As of the reading, CVE-2026-110264 was not in the KEV file.
So a defender who reads the KEV entry, follows the GitLab link in its notes and upgrades to 19.4.2 has closed CVE-2026-97229 and, by GitLab's own pages, left CVE-2026-110264 open on that line. The safer target is the 21 October release for the line in use, or later. This is an inference from the two GitLab pages, not a statement by CISA, and it should be checked against GitLab's current release notes before a change is scheduled.
The friendly name check: labels in this story and what the primaries say behind them, read 29 October 2026.
| Label | What it suggests | What the record says |
|---|---|---|
| Critical, CVSS 10.0 | A priority tells you what to do | CISA's FAQ says CVSS labels do not prescribe actions and replaces them with explicit timelines |
| Unauthenticated | Anyone on the internet can do it | GitLab's vector says no privileges required; a secondary report of a security firm's write up says a crafted file must reach a public project, which GitLab does not state and which was not read in the primary |
| Regexp.timeout or a pattern length limit | A guard that blunts a regular expression attack | Ruby says the timeout does not protect against these bugs and length limits do not reliably protect |
| Integer Overflow or Wraparound | A generic memory bug | GitLab's title is CI/CD Regular Expression Compiler; the KEV name is CWE-190's name |
| Patched to 19.4.2 | Done | Fixes this CVE; GitLab's 21 October page lists a later critical fix on the same line |
| GitLab.com is patched | The vendor has handled it | GitLab says so for its own hosted service and Dedicated; self managed instances are the customer's to upgrade |
What to do, in order
The order below puts evidence ahead of the patch, as CISA's own steps do, and treats the second CVE as part of the same job. Federal agencies have a due date of 1 November; everyone else has the same flaw and no deadline, which is not a reason to wait.
Take this with you
Defender actions, ranked
- Inventory every self managed GitLab instance, including test and forgotten ones, with its version and whether it can be reached from the internet. GitLab.com and GitLab Dedicated are patched by GitLab.
- For each instance below the fixed versions, decide scope first: who can sign up, who can create public projects, who can push CI configuration, and whether the instance faces the internet.
- Before changing an exposed instance, collect evidence as CISA's step 2 describes: volatile data, web and application logs, runner logs and a record of what was collected, by whom and when.
- Upgrade to GitLab's newest patch release for your line: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or later. That covers CVE-2026-97229 and CVE-2026-110264. Confirm against GitLab's current release notes.
- If the upgrade has to wait, GitLab prints no workaround for CVE-2026-97229. Reduce reach instead, as this site's inference: take the instance off the public internet or behind a VPN or allow list, close open sign up, and restrict who can push CI configuration.
- Hunt with GitLab's six detections for self managed instances, which are named in the technical details. Ask GitLab how to enable them for your edition. Neither GitLab nor CISA names a time window; the conservative start is 12 October, the first fix, and the public exploit was reported on 13 October by a secondary source.
- Review CI/CD configuration changes and runner logs for pipeline files or regular expressions that nobody on your team wrote, and check for new users, tokens, runners and project members on the instance.
- Work through CISA's triage steps in its order and finish with a written report that says no evidence, suspected or confirmed. If compromise is confirmed, federal agencies report to CISA; others follow their own incident process.
- Check Ruby applications that compile regular expressions from user input and upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13. Do not rely on Regexp.timeout or pattern length limits.
- Federal agencies and contractors: confirm whether the contract makes BOD 26-04 apply, and for FedRAMP offerings work through the FedRAMP office. Watch the KEV entry, because CISA says it will add indicators when it has them.
Technical details
These are the artifacts the primaries print for this CVE, copied as printed. The sources print no request payloads, no regular expression, no log lines and no indicators of compromise, and this briefing includes no exploit code and no crafted expression. The blocks are for matching versions, fields and detection names against your own instances and feeds.
The first block is CISA's entry in the KEV file, rendered as one line per field. A vulnerability management tool that ingests the KEV file will read these same keys. Use the forensicTriage and dueDate fields to route the finding to the triage process.
cveID: CVE-2026-97229
vendorProject: GitLab
product: Community Edition and Enterprise Edition
vulnerabilityName: GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability
dateAdded: 2026-10-29
dueDate: 2026-11-01
knownRansomwareCampaignUse: Unknown
forensicTriage: Yes
cwes: CWE-190
requiredAction: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA's BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA's "Forensics Triage Requirements" (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
notes: Other products can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue in CI/CD Regular Expression Compiler. For more information please see: https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves ; https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/ ; BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ; Forensics Triage Requirements: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk ; https://nvd.nist.gov/vuln/detail/CVE-2026-97229
The second block is the version and scoring data from GitLab's page and the CVE record, plus CISA's enrichment. Compare your instance's version string against the three ranges. GitLab's page prints the detection names but not how to switch them on.
CVE-2026-97229 - Integer Overflow issue in CI/CD Regular Expression Compiler impacts GitLab CE/EE
Impacted Versions: GitLab CE/EE: all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2
CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Detecting CVE-2026-97229 Exploitation Attempts (six threat detections for self managed instances):
Onigmo native worker crash
Graphql cilint hostile regexp
ci regexp oversized non ascii path
ci regexp guard rejection
ci lint workhorse worker crash
ci lint scripted client error burst
CVE record (CVE.org data, assigner GitLab), datePublished 2026-10-13
affected: GitLab, 19.2 lessThan 19.2.8; 19.3 lessThan 19.3.5; 19.4 lessThan 19.4.2 (semver)
problemType: CWE-190: Integer Overflow or Wraparound
solution: Upgrade to versions 19.2.8, 19.3.5, 19.4.2 or above.
CISA ADP enrichment, timestamp 2026-10-29T19:50:05Z
Exploitation: active
Automatable: yes
Technical Impact: total
The third pair covers the regular expression flaw that followed on 21 October and the Ruby fix list. If you run Ruby applications that build patterns from user input, match your interpreter version against the Ruby row.
CVE-2026-110264 - Integer Overflow issue in Regular Expression Compiler impacts GitLab CE/EE
Impacted Versions: GitLab CE/EE: all versions from 7.0 before 18.11.13, 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
CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Detections (two threat detections):
Onigmo native worker crash
Org mode render error burst
GitLab CVE: CVE-2026-93577, CVE-2026-97229
Bug in Ruby: Integer overflow in the size of a compiled pattern
Change: ruby/ruby pull request 19020
First release containing it: Ruby 4.0.8, 3.4.12, 3.3.13
Recommended action: upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13 or later.
If you cannot upgrade: avoid compiling regular expressions from untrusted input.
The question the three days cannot answer
CISA has said that someone is exploiting a flaw that GitLab fixed 17 days ago, and has given federal agencies three days and a triage duty, with a Sunday for a deadline. It has not said who, when or how many, and GitLab has not said anything about exploitation. The date on which your instance was first reachable with an unpatched version is knowable, and the date of the first hostile request is not. The question is whether your logs go back far enough, and were kept somewhere an attacker with code execution on the server could not reach, to tell you which side of that line you were on.
Sources
- PrimaryKnown Exploited Vulnerabilities file, catalogue version 2026.10.29 (released 29 October 2026, 19:09 UTC): the entry for CVE-2026-97229 with every field, the counts used for the derived figures, and the same day Cisco entry. Read in fullCISAaccessed 2026-10-29
- PrimaryKnown Exploited Vulnerabilities Catalog page: the statement that organisations should use the catalogue as an input to prioritisation and the entry display. ReadCISAaccessed 2026-10-29
- PrimaryBOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026: scope, required actions, phases, Table 1 and its notes, revocation of BOD 19-02 and BOD 22-01. Read in fullCISAaccessed 2026-10-29
- PrimaryBOD 26-04 Implementation Guidance (updated 25 August 2026): the six forensic triage steps, the KEV criteria, the dueDate FAQ, the no waivers FAQ and the CVSS note. Read in fullCISAaccessed 2026-10-29
- PrimaryBOD 22-01 (revoked) page: the two weeks and six months timelines and its scope, for the comparison with BOD 26-04. ReadCISAaccessed 2026-10-29
- PrimaryGitLab Critical Patch Release 19.4.2, 19.3.5, 19.2.8, dated 12 October 2026: the CVE-2026-97229 entry, versions, CVSS vector, six detections, the 19.3.4 bug and the disclosure statement. The vendor's own advisory, read in fullGitLabaccessed 2026-10-29
- PrimaryGitLab Critical Patch Release 19.5.1 and backports, dated 21 October 2026: CVE-2026-110264, its affected versions, CVSS 10.0 and two detections. ReadGitLabaccessed 2026-10-29
- PrimaryGitLab patch release feed: used to confirm that the 21 October release was the newest patch release listed at the time of readingGitLabaccessed 2026-10-29
- PrimaryCVE record for CVE-2026-97229: description, affected versions, solution, CVSS and CISA's Authorized Data Publisher enrichment with its 19:50 UTC timestamp. Read in fullCVE Program (GitLab as CNA)accessed 2026-10-29
- PrimaryNVD record for CVE-2026-97229: status Undergoing Analysis, last modified 29 October 2026, the CPE ranges and the CISA SSVC data. ReadNIST NVDaccessed 2026-10-29
- PrimaryRuby news post of 23 October 2026: regular expression compilation fixes behind the four GitLab CVEs, the fixed Ruby releases and the statement that Regexp.timeout does not protect. Read in fullRuby projectaccessed 2026-10-29
- Reported byArticle of 14 October 2026: reports a proof of concept from a security firm on 13 October, a scanning firm's count of exposed hosts and no confirmed exploitation at that time. Secondary; the primary pages were not readDaily Security Reviewaccessed 2026-10-29
