CVE-2026-97229: GitLab CI/CD Regex RCE (CVSS 10.0) Exploited, in CISA KEV

This week in our InSEKurity of the Week series: the platform that holds your source code, your CI/CD secrets and your deployment pipelines. On October 12, 2026, GitLab released critical patch versions 19.4.2, 19.3.5 and 19.2.8 for CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler rated CVSS 10.0. A specially crafted regular expression in a CI/CD configuration lets an attacker execute arbitrary code on the GitLab server — as the git operating-system account that owns every repository on the box. On October 29, CISA added the flaw to its Known Exploited Vulnerabilities catalog.

The bug is not really in GitLab’s code. It lives in Onigmo, the regular expression engine built into Ruby, and GitLab fixed it by patching the Ruby interpreter it ships inside its own packages and container images. That detail turned out to matter: Alpine Linux — whose GitLab instance runs on the distribution’s own Ruby — upgraded GitLab, stayed vulnerable, and watched an attacker crash its GitLab workers eight times while trying to exploit exactly this flaw. Alpine could not rule out success and rebuilt the server from scratch.

And CVE-2026-97229 has a sibling. Nine days later, GitLab shipped another round of critical releases for CVE-2026-110264, a second CVSS 10.0 overflow in the same engine that reaches back to GitLab 7.0 (2014). If you patched on October 12 and stopped there, you are not done.

🚨 Summary

CVE ID: CVE-2026-97229 — “Integer Overflow issue in CI/CD Regular Expression Compiler impacts GitLab CE/EE”
CVSS 3.1 Score: 10.0 Critical (GitLab as CNA), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE: CWE-190: Integer Overflow or Wraparound
Vendor Advisory: GitLab Critical Patch Release 19.4.2, 19.3.5, 19.2.8, published 2026-10-12
Affected Software: Self-managed GitLab Community Edition and Enterprise Edition 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2 — across all deployment types (Linux package, Docker, Helm, source). GitLab.com and GitLab Dedicated are already patched
Underlying Component: Ruby’s Onigmo regex engine; upstream fixed in Ruby 3.3.13, 3.4.12 and 4.0.8 (4.0.9 contains all related fixes)
Attack Vector: Network — a crafted regular expression in a CI/CD configuration that GitLab evaluates
Authentication Required: Rated none by GitLab. The public exploit path needs the ability to push to a public project once, then triggers the bug with a request that carries no credentials at all. On instances with open self-registration, that is no barrier
Impact: Remote code execution as the GitLab git account inside a Puma worker — full access to repositories, CI/CD variables, runner tokens and the application’s secrets
Patch Status: Available since 2026-10-12. The follow-up flaw CVE-2026-110264 requires the 2026-10-21 releases (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13) or later
Self-compiled / custom Ruby: Upgrading GitLab alone is not enough — the Ruby interpreter must be 3.3.13, 3.4.12, 4.0.9 or later
Exploitation Status: Public PoC from Rapid7 since 2026-10-13; exploitation attempted against Alpine Linux’s GitLab on 2026-10-20/21
CISA KEV: Listed since 2026-10-29; federal due date 2026-11-01

🖥️ What is GitLab?

GitLab is a complete DevSecOps platform in a single application: Git repository hosting, merge requests and code review, issue tracking, a container and package registry, and — at its core — GitLab CI/CD, the pipeline engine that builds, tests and deploys code. GitLab says its platform is used by more than 50% of the Fortune 100 and counts more than 70 million registered users.

Unlike GitHub, GitLab is very commonly run self-managed: on a VM from the Linux package (“Omnibus”), as the official Docker image, on Kubernetes via Helm, or compiled from source. That is what puts CVE-2026-97229 in the hands of individual admin teams — GitLab.com was fixed before disclosure, every self-managed instance was not.

Typical Use Cases

Source code management for internal products, infrastructure-as-code and configuration repositories
CI/CD pipelines that hold deployment credentials, cloud keys, signing keys and registry tokens as CI/CD variables
Container and package registries that feed production deployments
Open-source project hosting — such as Alpine Linux’s gitlab.alpinelinux.org — with public projects and open registration
Regulated environments where the platform must stay on-premises for compliance reasons

Why a GitLab Server Is a Crown Jewel

A GitLab server is a supply-chain control point. Code execution as git means read and write access to every repository on the instance, to the encrypted secrets the application can decrypt, and to the runner tokens that connect it to build infrastructure. An attacker who controls GitLab does not need to break into production — they can wait for production to deploy their code.

🔍 Technical Analysis

Vulnerability Description

GitLab lets pipeline authors use regular expressions in CI/CD configuration — for example in rules:exists and rules:changes, which decide whether a job or an included file applies depending on which paths exist or changed in a commit. GitLab compiles those user-supplied patterns with Ruby’s built-in engine, Onigmo, and validates them before use: a source-length check, a check for subroutine calls (\g), a scanner that rejects oversized repeat bounds, a probe compile, a 50 ms timeout and a 1 MB cap on the compiled object.

CVE-2026-97229 slips a pattern through all of these. When Onigmo later compiles the pattern for a UTF-8 subject, a signed integer multiplication overflows, the engine emits a gigantic program, and a jump inside that program points to the wrong place. The result is attacker-influenced control flow inside the Ruby process — code execution on the GitLab server.

Root Cause Analysis

Rapid7’s technical analysis, which reproduced the bug end to end against the official 19.4.1 CE image, describes four ingredients:

A validator that reads the pattern differently from the engine. GitLab’s REPEAT_BOUND scanner only recognises contiguous digits inside {...}. An inline regex comment (?#) placed inside the quantifier braces splits the number: Onigmo ignores the comment and reads the full, large repeat bound, while GitLab’s scanner sees a small one and lets it pass.
A size check on the wrong compilation. The pattern is validated as US-ASCII, where it is small. When the subject is a file path containing UTF-8 characters, Ruby’s rb_reg_prepare_re() recompiles the pattern for the new encoding — and POSIX word classes expand into large Unicode tables. That recompile happens before the timed match starts and is never size-checked.
A signed overflow in Onigmo’s expansion decision. In compile_quantifier_node(), Onigmo decides whether to unroll a bounded quantifier by multiplying body size by the upper bound in a signed integer. In Rapid7’s example, a 37,151-byte body times a bound of 57,805 is 2,147,513,555 — 29,908 past INT_MAX. The product wraps negative, the “small enough to expand” test passes, and Onigmo emits every copy.
A jump computed from a wrapped length. The OP_JUMP that skips an empty alternative is calculated from the already-overflowed length and lands inside the expanded program instead of after it. Attacker-shaped bytes at the end of the copies are then executed by Onigmo’s VM; Rapid7’s chain pivots from there into a system() call in libruby.

GitLab’s backport replaces the multiplication with a division-based check (IS_EXPAND_LIMIT_OK) and rejects compiled programs above roughly 512 MiB (MAX_COMPILED_PROGRAM_SIZE). The Ruby project shipped the same fix upstream as CVE-2026-93577 (“integer overflow in the size of a compiled pattern”) and states plainly that Regexp.timeout does not protect against these bugs, and that limiting pattern length does not reliably prevent them either.

Attack Vector

The demonstrated path has two steps: an authenticated setup that plants the payload, and an unauthenticated trigger that makes GitLab evaluate it.

# ILLUSTRATIVE ONLY -- data flow of Rapid7's published chain; NOT a functional exploit.
# The real payload bytes and offsets are build-specific and intentionally omitted.

 attacker account with push access to ANY public project
   |   (on instances with open sign-up: register, create a public project)
   |
   | 1. push branch "payload-ref" containing:
   |      - .gitlab-ci.yml using rules:exists / rules:changes with a regexp
   |        whose repeat bound is split by an inline comment  {NNN(?#)NN}
   |      - repeated POSIX word classes (small in ASCII, huge in UTF-8)
   |      - a committed file path made of 4-byte UTF-8 characters
   v
 anonymous HTTP client (no token, no cookie)
   |
   | 2. GET /api/v4/projects/<public-project>/ci/lint?content_ref=payload-ref
   v
 GitLab Puma worker (runs as OS user "git")
   |  validates regexp as US-ASCII .......... passes
   |  matches against UTF-8 path ............ Ruby recompiles for UTF-8
   |  Onigmo: body_size * repeat_bound ...... signed overflow -> expands anyway
   |  misplaced OP_JUMP ...................... VM executes attacker bytes
   v
 system("<attacker command>") as git  ->  worker crashes afterwards, HTTP 502

The trigger request, as documented by Rapid7, is a plain GET against the project-scoped CI lint endpoint:

# ILLUSTRATIVE ONLY -- request shape for log review and detection.
# Taken from Rapid7's analysis; it does nothing without the planted payload.
GET /api/v4/projects/attacker%2Fpublic-project/ci/lint?content_ref=payload-ref HTTP/1.1
Host: gitlab.example.com
User-Agent: Mozilla/5.0
Accept: */*

Three properties of this request are worth noting for defenders. It carries no authentication — the endpoint’s read check passes because the project is public, and the token check does not reject a request without a user. The lint route does not create a pipeline or contact a runner, so nothing shows up in the pipeline list. And a successful run ends with the worker crashing after system() returns, so the attacker sees an HTTP 502 — which is exactly what the PoC README tells its users to expect.

Rapid7 openly notes that its setup step conflicts with GitLab’s PR:N rating: the original HackerOne report by joaxcar (Johan Carlsson) is private, and how it avoids the write prerequisite is not public. The practical takeaway is the one Rapid7 states: on instances where new users can self-register and create projects, the constraint disappears.

The Sibling: CVE-2026-110264

On October 21, GitLab shipped critical releases 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for CVE-2026-110264 — “Integer Overflow issue in Regular Expression Compiler impacts GitLab CE/EE”, again CVSS 10.0, again reported by joaxcar. The Ruby project describes it as an overflow of internal IDs in a pattern with many repeats. It affects all versions from 7.0, so the October 12 releases are still exposed. GitLab’s published detection names an “Org mode render error burst”; according to Konfirmity’s summary of that rule, this variant is reached through Org mode rendering, where the org-ruby gem builds a regex from a #+TODO: keyword without escaping it.

Exploitation in the Wild

2026-10-13 — Rapid7 publishes its assessment and a public proof-of-concept that executes commands as git on the official gitlab/gitlab-ce:19.4.1-ce.0 image.
2026-10-20 to 21 — A newly registered account probes Alpine Linux’s GitLab instance and sends crafted CI configurations. GitLab worker processes crash eight times; in four of those crashes, the attacker got partway through the exploit before failing at the next step. The attacker also downloads Alpine’s GitLab container image — in Alpine’s words, a sign they were tuning the exploit to that specific build.
2026-10-25 to 26 — The attacker returns and tries to regain access; the attempts fail.
2026-10-28 — Alpine publishes its disclosure: “The attack came close to working”. No evidence of success, but it “cannot rule it out” and treats the instance as compromised.
2026-10-29 — CISA adds CVE-2026-97229 to the KEV catalog. GitLab says it detected exploitation attempts and has released threat detections for self-managed customers.

Alpine’s root cause is instructive. On October 13 it upgraded to 19.3.4 instead of 19.3.5 by mistake. On October 22 it upgraded to 19.3.6 — which also did not help, because Alpine’s own GitLab image runs the distribution’s stock Ruby, not GitLab’s patched one. Only the image published on October 27 with Ruby 3.3.13 closed the hole.

Post-Exploitation Impact

Command execution as git — the account that owns all repository data, uploads and the application’s working directory.
Secret exposure — CI/CD variables, runner registration and authentication tokens, webhook and integration credentials, push mirror credentials and 2FA secrets (Alpine’s own list of potentially exposed data).
Source code theft — private repositories, confidential issues and merge requests.
Supply-chain manipulation — altering code, CI definitions or release artifacts so that downstream builds deliver the attacker’s payload.
Pivot into build infrastructure — runner tokens and cloud credentials stored as CI/CD variables open the path from GitLab into deployment targets.
Credential reuse — user password hashes; Alpine notes the attacker was also trying passwords leaked from other sites.

📊 Impact Assessment

Immediate Impact

Full compromise of a self-managed GitLab instance by anyone who can push to one public project — or create one.
A successful exploit leaves very little trace: Alpine notes it would leave no crash and no web-log trace, only the failed attempts are noisy.
Upgrading the GitLab version string does not guarantee a fix on self-compiled installs and custom images.

Affected Versions

Component	Affected	Fixed
GitLab CE/EE 19.4 (CVE-2026-97229)	19.4.0 — 19.4.1	19.4.2
GitLab CE/EE 19.3 (CVE-2026-97229)	19.3.0 — 19.3.4	19.3.5
GitLab CE/EE 19.2 (CVE-2026-97229)	19.2.0 — 19.2.7	19.2.8
GitLab CE/EE (CVE-2026-110264)	all from 7.0	19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
GitLab CE/EE 18.10 and older	—	No fix; upgrade to a supported line
Ruby (self-compiled / custom images)	3.3 < 3.3.13, 3.4 < 3.4.12, 4.0 < 4.0.9	3.3.13, 3.4.12, 4.0.9
Ruby 3.2	affected	No fix planned
GitLab.com / GitLab Dedicated	—	Already patched, no action

The current patch releases at the time of writing are 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 and 18.11.14 (GitLab skipped 19.5.2 and 19.4.4). They contain both regex fixes plus an unrelated certificate-trust fix (CVE-2026-111943). Upgrading straight to the newest patch on your line is the simplest way to be covered.

Affected Environments

Instances with open self-registration — the write prerequisite of the public exploit path costs the attacker one sign-up.
Open-source and community instances with public projects, like Alpine’s.
Self-compiled GitLab and custom container images that bring their own Ruby — the GitLab upgrade does not carry the fix.
Internet-exposed instances in general. Shadowserver tracks nearly 2,800 internet-exposed GitLab Community Edition instances.
Internal instances are reachable by any insider, contractor or compromised developer account that can push to a public or internal project.

Attacker Profiles

Supply-chain actors targeting open-source infrastructure — the Alpine attacker downloaded the target’s own container image to tailor the exploit.
Initial-access brokers and ransomware affiliates, for whom a GitLab server is a high-value foothold with credentials to everything that deploys from it.
Espionage actors interested in source code and the secrets embedded in CI/CD.
Opportunistic attackers reusing the public PoC against instances with open registration.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

1. Determine your exact GitLab version (and, for source installs, your Ruby).

# Linux package (Omnibus): prints GitLab, GitLab Shell and system information.
# Check the "Version:" line under "GitLab information" and the "Ruby Version:" line.
sudo gitlab-rake gitlab:env:info

# Docker: run the same Rake task inside the container (replace <container> with its name)
docker exec <container> gitlab-rake gitlab:env:info

# Remotely via the REST API (requires an access token);
# the "version" field returns e.g. "19.4.5-ee"
curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/metadata"

# Self-compiled installation: run from the GitLab directory (e.g. /home/git/gitlab) as the git user
bundle exec rake gitlab:env:info RAILS_ENV=production

# Self-compiled or custom image: the Ruby that actually runs GitLab must be
# 3.3.13, 3.4.12, 4.0.9 or later -- the GitLab version alone proves nothing here
ruby -v

Compare against the table above. On the Linux package and the official images, GitLab’s patched Ruby is part of the release — the GitLab version is what counts. On self-compiled installs and custom images, both numbers must be fixed.

2. Upgrade to the newest patch release on your line.

# Debian/Ubuntu, Linux package -- pin the exact version (example: latest 19.4 patch).
# Use gitlab-ce=19.4.5-ce.0 for Community Edition.
sudo apt update && sudo apt install gitlab-ee=19.4.5-ee.0

# RHEL / AlmaLinux / Oracle Linux 9 -- use .el8 on version 8
sudo dnf install gitlab-ee-19.4.5-ee.0.el9

# Docker: pull the fixed image tag, then recreate the container with it
docker pull gitlab/gitlab-ce:19.4.5-ce.0

Single-node instances have downtime during this upgrade because database migrations must finish before GitLab starts; multi-node setups can use the zero-downtime procedure. Upgrading GitLab does not update GitLab Runner — update self-managed runners separately.

3. If you run your own Ruby, upgrade Ruby as well. For self-compiled installs and custom images, install Ruby 3.3.13, 3.4.12 or 4.0.9 (or later) from your distribution or build. Alpine-based images: apk upgrade ships Ruby 3.3.13 on Alpine 3.21 and 3.4.12 on 3.22, 3.23, 3.24 and edge. Users of alpinelinux/gitlab:19.3.6 must re-pull — only images published on October 27 or later contain the fixed Ruby.

4. Until you can patch: remove the cheap write path. Rapid7 recommends restricting anonymous access to public projects and preventing untrusted users from creating or writing to them. As an administrator:

# Disable self-registration and stop non-admins from using the "public" visibility level.
# Requires an administrator token. Existing public projects keep their visibility --
# review them separately (Admin area > Projects, filter by visibility).
curl --request PUT \
  --header "PRIVATE-TOKEN: <admin_access_token>" \
  --url "https://gitlab.example.com/api/v4/application/settings" \
  --data "signup_enabled=false" \
  --data "restricted_visibility_levels[]=public"

Blocking the /api/v4/projects/:id/ci/lint route at a reverse proxy or WAF interrupts the demonstrated trigger, but Rapid7 is explicit that these controls address only the demonstrated delivery path and do not remediate the vulnerable regular expression compiler. They buy time; they are not a fix.

Detection Measures

GitLab has released threat detections for self-managed instances — among them “Onigmo native worker crash” and “Org mode render error burst” — in its open TLDR detection repository. The following checks implement Rapid7’s published indicators on a Linux package installation (default log paths):

# 1. Anonymous CI lint requests that ended in HTTP 502 -- the PoC's expected outcome.
#    Workhorse writes JSON access logs; adjust the date filter to your retention.
sudo grep -E '/api/v4/projects/[^ "]+/ci/lint' /var/log/gitlab/gitlab-workhorse/current \
  | grep -E '"status":502'

# 2. The matching Workhorse error when the Puma worker died mid-request
sudo grep -F 'badgateway: failed to receive response' /var/log/gitlab/gitlab-workhorse/current

# 3. All CI lint API calls on the Rails side, to correlate project, ref and client IP
sudo grep -F '/ci/lint' /var/log/gitlab/gitlab-rails/api_json.log

# 4. Ruby/Onigmo crashes of Puma workers -- a trace mentioning regexp_matcher.rb is a strong signal
sudo grep -E -i 'onigmo|regexp_matcher\.rb|\[BUG\]|Segmentation fault' /var/log/gitlab/puma/puma_stderr.log

GitLab’s post-compromise guidance names the places to look on the host itself:

# 5. Files owned by the git user in temp directories, created since the 19.4.2 release
sudo find /tmp /var/tmp -user git -newermt '2026-10-12' -ls

# 6. Process tree of the git user -- a shell, curl, wget or python below a Puma/Sidekiq
#    Ruby process is the strongest indicator of successful exploitation
ps -u git -o pid,ppid,etime,args --forest

# 7. Crontab of the git user -- look for entries nobody on your team created
sudo crontab -l -u git

# 8. Established TCP connections with owning process -- look for shells or download
#    tools owned by git talking to unexpected destinations
sudo ss -tnp | grep -E 'users:\(\("(sh|bash|dash|curl|wget|python3?|perl)"'

Also review the git user’s SSH keys for entries you did not expect, and keep in mind Alpine’s warning: a successful exploit may leave none of the crash noise above.

# Sigma rule -- shell or download tool spawned by GitLab's Ruby processes (Linux process creation).
# Starting point only: tune out legitimate child processes in your environment before alerting.
title: Shell Spawned by GitLab Ruby Process as git User
id: 2f6d7a4e-3c1b-4b8e-9a51-7e0c2d9f4a10
status: experimental
description: Detects a shell or download tool started by the GitLab embedded Ruby (Puma/Sidekiq) as the git user, as seen in CVE-2026-97229 exploitation.
references:
  - https://www.rapid7.com/blog/post/ra-gitlab-ci-cd-regex-integer-overflow-technical-analysis-cve-2026-97229/
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith: '/opt/gitlab/embedded/bin/ruby'
    User: 'git'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python3'
      - '/perl'
  condition: selection_parent and selection_child
level: high
tags:
  - attack.execution
  - attack.t1059.004
  - cve.2026-97229

If you find signs of code execution, follow GitLab’s guidance: rotate the secrets in gitlab-secrets.json, all CI/CD variables, runner tokens and access tokens — and, as Alpine did, consider rebuilding the instance rather than cleaning it.

Long-term Security Improvements

Treat the bundled runtime as part of the product. Track the Ruby (and other interpreters) inside your GitLab image in your SBOM and patch process — especially for self-compiled installs and custom images.
Patch critical GitLab releases within a day. Alpine’s own lesson; check every release note for Ruby or other component patches your build must apply.
Close open registration or require admin approval for new sign-ups (require_admin_approval_after_user_signup), and default new projects to private.
Log outbound connections from the GitLab host and database connections, and retain logs longer than 14 days — Alpine lost logs from the attack day.
Minimise secrets in CI/CD variables: prefer short-lived, OIDC-based credentials over long-lived cloud keys.
Sign release tags and artifacts so releases can be verified independently of the GitLab server.
Isolate the GitLab host from production networks; a compromised GitLab server should not be able to reach everything it deploys to.
Never reuse passwords across services — the Alpine attacker also tried credentials leaked elsewhere.

⚠️ Why is this Critical?

Maximum severity, confirmed exploitation — CVSS 10.0 and listed in CISA KEV with a three-day federal deadline.
A public, working PoC — Rapid7’s chain reliably executes commands on the official 19.4.1 image.
“Unauthenticated” in practice on any instance with open registration and public projects.
The patch can silently miss — custom images and self-compiled installs need a Ruby upgrade that the GitLab version string does not reveal.
Two CVSS 10.0 bugs in one engine within nine days — October 12 patches do not cover CVE-2026-110264.
Supply-chain blast radius — source code, CI/CD secrets and the path into every deployment target sit on the same server.

📅 Timeline and Disclosure

2026-10-12 — GitLab releases 19.4.2, 19.3.5 and 19.2.8, fixing CVE-2026-97229 (reported via HackerOne by joaxcar) with a patched Ruby in its packages and images.
2026-10-13 — Rapid7 publishes its assessment and a public PoC; Help Net Security urges admins to patch. Alpine Linux upgrades to 19.3.4 instead of 19.3.5 by mistake.
2026-10-16 — Rapid7 publishes its full technical analysis.
2026-10-20 / 21 — An attacker sends crafted CI configurations to Alpine’s GitLab; eight worker crashes, 502 errors and failed CI jobs.
2026-10-21 — GitLab releases 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, fixing the sibling flaw CVE-2026-110264 (all versions since 7.0).
2026-10-22 — Alpine upgrades to 19.3.6, still vulnerable because its image uses stock Ruby.
2026-10-23 — Ruby releases 4.0.9, 3.4.12 and 3.3.13 with the regex fixes; Alpine blocks the attacker’s account.
2026-10-25 / 26 — The attacker’s attempts to regain access fail; Alpine finds its instance still vulnerable.
2026-10-27 — Alpine restricts GitLab to developers and build servers, rebuilds, and publishes alpinelinux/gitlab:19.3.6 with Ruby 3.3.13.
2026-10-28 — Alpine completes the rebuild, rotates secrets and publishes its incident report.
2026-10-29 — CISA adds CVE-2026-97229 to the KEV catalog; GitLab confirms exploitation attempts and releases detections.
2026-11-01 — Remediation due date for US federal civilian agencies.

📚 Resources and References

🤝 SEKurity Supports You

Most organisations protect their GitLab like an internal tool — and it is anything but. It is where your source code lives, where your deployment credentials are stored and where your release process starts. CVE-2026-97229 shows how thin the line is: one public project, one crafted regex, and an anonymous request turns that platform into the attacker’s.

The useful questions this week are concrete. Can anyone on the internet register an account on your GitLab? Which public projects exist, and who can push to them? Does your GitLab image use GitLab’s Ruby or your own? Which secrets live in CI/CD variables, and what could a git shell do with them? And would your logs have shown eight worker crashes on a Wednesday night — and would anyone have looked?

We test DevOps platforms and CI/CD pipelines from the attacker’s perspective — from the unauthenticated outside, from a developer account, and from a compromised runner — and show you how far a foothold in your toolchain really reaches. If your GitLab has never been part of a penetration test, this is the week to change that.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/en/contact

LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your DevOps platforms and software supply chain is our drive.

Sources

GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 — release date, CVE-2026-97229 title and description, CVSS vector, reporter, affected versions, bundled Ruby regex patches, Onigmo worker crash detection, upgrade downtime notes
GitLab — Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 — CVE-2026-110264, affected versions from 7.0, backports, detections, upgrade notes
GitLab — Patch Release and Security Update: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14 — current patch versions, skipped 19.5.2/19.4.4, separate Runner update
Ruby — Regexp fixes for GitLab CVEs — mapping of CVE-2026-97229 to CVE-2026-93577, fixed Ruby versions, Regexp.timeout limitation, credit to Johan Carlsson (joaxcar)
Rapid7 — CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab — assessment, PoC validation on 19.4.1, self-registration caveat, interim mitigations
Rapid7 — GitLab CI/CD Regex Integer Overflow: Technical Analysis — root cause, (?#) bypass, UTF-8 recompile, overflow arithmetic, fix details, preconditions, indicators and log paths
GitHub — jburgess-r7/CVE-2026-97229-PoC — PoC prerequisites, anonymous trigger, gitlab/gitlab-ce:19.4.1-ce.0 image tag, expected HTTP 502
Alpine Linux — GitLab security incident (CVE-2026-97229) — attack timeline, 19.3.4 mistake, stock Ruby gap, recommendations for GitLab admins
The Hacker News — Attacker Tried to Exploit Alpine Linux’s GitLab via CVSS 10.0 Flaw Its Ruby Left Open — incident details, potentially exposed data, GitLab’s post-compromise checks and secret rotation guidance
The Hacker News — CISA Adds Actively Exploited GitLab RCE and Cisco Firewall DoS Flaws to KEV — KEV addition, federal due date, other CW44 candidates considered
BleepingComputer — CISA says max severity GitLab flaw now exploited in the wild — GitLab exploitation attempts and detections, Shadowserver exposure, Fortune 100 and user numbers
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog (2026-10-29) — KEV addition date
Konfirmity — GitLab CVE-2026-110264 RCE: Fixed Versions — fixed-version matrix, Org mode / org-ruby attack path summary
DEV Community — GitLab Was Patched, the Server Was Still Vulnerable: CVE-2026-97229 Lives in Ruby — package vs. source-install distinction, Alpine image guidance
Help Net Security — GitLab admins urged to patch critical RCE flaw (CVE-2026-97229) — disclosure coverage
GitLab Docs — Upgrade Linux package instances, Maintenance Rake tasks, Metadata API, Application settings API, Log system — commands, version formats, API attributes and log paths used in this article
CISA — Known Exploited Vulnerabilities Catalog — KEV status
EntryZero — Top 5 Hacker-relevant Vulnerabilities (weekly briefing) — weekly vulnerability briefing consulted for topic selection

InSEKurity of the Week (CW44/2026): GitLab CI/CD Regex Integer Overflow RCE (CVE-2026-97229)