A Crafted Pattern Could Reach Your GitLab Server
Update, 30 October 2026: CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalogue on 29 October. Self-managed GitLab teams should prioritise checking their installed versions and reviewing evidence from the period before patching. Assess each installation’s logs and other evidence before concluding that it was compromised.
The fix levels in the original report below date from 12 October. GitLab’s maintenance policy currently lists 19.5, 19.4 and 19.3; its current patch notes list 19.5.3, 19.4.5 and 19.3.7 for those branches. Select the latest applicable maintained release through GitLab’s supported upgrade path.
Ruby’s 23 October advisory connects the underlying integer overflow to Onigmo’s compilation of attacker-controlled patterns and explains that GitLab patched the Ruby it ships. Ruby says the bugs require an application to compile attacker-controlled patterns. Timeouts and pattern-length limits are not reliable substitutes for the upstream fixes; other Ruby applications need their own exposure assessment rather than an assumption that GitLab’s patch updates them.
The original release and affected branches
GitLab’s 12 October patch notice lists 19.4.2, 19.3.5 and 19.2.8 as the original fix levels for CVE-2026-97229.
Server exposure
Under the conditions described by GitLab, the CVSS 3.1 score 10.0 flaw could let an unauthenticated user turn a crafted CI/CD regular expression into server-side code execution.
Match the running minor branch to the affected ranges in the 12 October notice:
- 19.2 before 19.2.8
- 19.3 before 19.3.5
- 19.4 before 19.4.2
Who needs to act
For this flaw, GitLab.com was already patched when the 12 October notice was published; GitLab Dedicated tenants had received an internal patched release. The action here concerns self-managed instances.
Urgency still needs disciplined change control. Start by inventorying each self-managed instance and recording its current minor branch. Select the fixed build for that branch, validate backups and rollback steps, and stage the change through the supported upgrade path. Do not substitute a different fixed branch without checking GitLab’s upgrade requirements.
Upgrade timing
For the 12 October patch series, single-node upgrades need downtime; multi-node deployments can use GitLab’s zero-downtime procedure when its requirements are met. For 19.3.5, plan post-deploy migrations. Check the migration notes for the newer release you select: the current patch notice lists regular migrations for 19.5.3 and 19.4.5.
The 19.3.5 release also fixed the merge-request-page regression that affected 19.3.4 when the Ona integration was enabled.
Operators should use the supported upgrade path, then run their normal functional checks before closing the change.
What to verify after the change
Confirm the running application version on every node, and test project access, merge requests and a controlled CI pipeline.
Review administrative and application logs covering the period before patching, and use the detection guidance linked from GitLab’s current notice where applicable. The notice links six detections covering worker crashes, hostile regular expressions and CI-lint activity. Treat those as investigation signals, not guaranteed coverage. CISA’s 29 October KEV addition records known exploitation of this vulnerability. A vulnerable version alone does not establish that an individual instance was compromised.
Sources: GitLab’s 12 October patch notice; CERT-EU’s original advisory; CISA’s KEV data; GitLab’s maintenance policy; GitLab’s current patch notes; Ruby’s compiler-fix advisory.
