GitLab CVE-2026-97229: patch actively exploited CI/CD RCE now

Urgency: Critical for any internet-reachable or untrusted-user GitLab instance. This is a documented, actively exploited vulnerability; it is not a reason to run a proof of concept.

CVE: CVE-2026-97229
Product: GitLab Community Edition (CE) and Enterprise Edition (EE)
Affected / fixed: 19.2 before 19.2.8; 19.3 before 19.3.5; 19.4 before 19.4.2. Versions outside those stated release lines need vendor release-note confirmation.
CVSS: 10.0 (CVSS v3.1, vendor/NVD record).
EPSS: 27.30% on 1 November 2026 (FIRST EPSS); this is a model estimate, not evidence that your instance was attacked.
Exploitation: Confirmed. CISA added the CVE to KEV on 29 October 2026.
Author urgency assessment: Patch on an emergency change window if the GitLab UI is reachable by untrusted users or projects; otherwise patch at the next controlled window and review access immediately.

What is confirmed

GitLab states that a specially crafted regular expression in a CI/CD configuration could allow an unauthenticated user to execute code on the GitLab server under certain conditions. The affected release ranges are 19.2.x before 19.2.8, 19.3.x before 19.3.5 and 19.4.x before 19.4.2.

CISA’s KEV listing means exploitation has been observed; it does not identify every vulnerable instance, show that your server was targeted, or prove compromise. Do not validate exposure by importing a malicious pipeline or regular expression.

Are you affected?

First establish the running version and where users can submit CI/CD configuration.

Omnibus Linux package

sudo gitlab-rake gitlab:env:info
sudo gitlab-rake gitlab:check SANITIZE=true

Expected result: the environment report contains the GitLab version and the check completes without configuration errors. Record the output in the change ticket. A reported vulnerable release is affected; a supported fixed release is not affected by this specific version condition, provided the package version actually deployed matches the report.

Docker

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker exec gitlab gitlab-rake gitlab:env:info

Expected result: the container image and in-container version agree. If they differ, treat the runtime report as authoritative and investigate image/tag drift.

Source installation

sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

Run this from the GitLab application directory. Preserve the output, but do not paste tokens, secrets or full configuration into a ticket.

Exposure increases where the GitLab web interface is internet-facing, self-registration or external project contributions are allowed, or untrusted users can propose CI configuration. Private network placement reduces reachability but does not remove risk from authenticated internal users or exposed reverse proxies.

Patch: supported remediation

Prerequisites

1. Open an emergency change and notify GitLab administrators and CI owners.
2. Confirm backups are recent and restorable: database, repositories, uploads, configuration and secrets. A backup is not proof until a restore test exists.
3. Record the current version, running containers/services and reverse-proxy health.
4. Schedule a maintenance window: GitLab upgrade tasks can stop web and job processing.

Omnibus package upgrade

Follow GitLab’s supported upgrade-path documentation; do not skip required intermediate versions. On a host already on 19.2, 19.3 or 19.4, move to at least 19.2.8, 19.3.5 or 19.4.2 respectively:

sudo apt-get update
sudo apt-cache madison gitlab-ee   # use gitlab-ce for CE
sudo apt-get install gitlab-ee=<approved-fixed-version>
sudo gitlab-ctl reconfigure
sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true

On RPM platforms, use the equivalent supported package-manager command and the approved fixed package. Expected result: all GitLab services are running, the version command reports the fixed release, and gitlab:check passes. If package migration fails, keep the failed-state logs and use GitLab’s documented restore procedure; do not downgrade database schema casually.

Docker or Helm deployment

Update the image/chart only through GitLab’s documented upgrade path, pin the fixed version rather than latest, then verify the live pod/container version. Expected result: every web, Sidekiq and toolbox component reports the same fixed GitLab release; a successful image pull alone is not validation.

Temporary containment while waiting for a patch

There is no vendor-supported configuration switch that replaces the update. Until the maintenance window:

• restrict GitLab web access at the reverse proxy/VPN to named administrators and required CI runners;
• temporarily disable public registration and review project/group membership;
• pause external integrations that can create or modify CI configuration where operationally feasible;
• preserve web, application, audit and runner logs before changing retention or access controls.

These measures reduce opportunity but do not make a vulnerable instance safe. Remove temporary allowlists only after the patch validation and monitoring review.

Safe discovery and evidence

Review GitLab audit events, web access logs, application logs and CI configuration changes around the KEV addition and your own exposure period. Look for unexpected project creation, pipeline configuration edits, new access tokens, runner changes, unusual jobs, outbound connections or unexplained server processes. These are investigation leads, not proof of exploitation.

If suspicious activity is found, preserve logs and relevant VM/container snapshots according to your incident process before rebuilding credentials or changing configuration. Rotate GitLab administrator, runner, deploy and integration tokens after containment, prioritising tokens reachable from the affected server.

NetTools.tech: no external NetTools.tech check is suitable for determining whether CVE-2026-97229 is present. An internet scan cannot safely prove the GitLab version or patch state; use authenticated local version evidence instead.

Validate and monitor

After deployment:

1. Re-run the version command and save the output with the change record.
2. Confirm the web UI, SSH Git access, an existing harmless pipeline and runner registration work as expected.
3. Check gitlab-ctl status (or pod health) and gitlab-rake gitlab:check SANITIZE=true.
4. Review GitLab audit events and error logs for upgrade-time failures or unexpected CI changes.
5. Keep heightened monitoring for administrative changes, token creation and runner configuration changes.

Rollback

Do not roll back an upgraded GitLab database by installing an older package. If the release causes a service-impacting failure, use the tested vendor-supported restore/rollback procedure from a verified pre-upgrade backup, involve the GitLab administrator, and maintain the network restrictions above until the vulnerable version is no longer exposed.

Timeline

• 13 October 2026: CVE record published.
• 29 October 2026: CISA added CVE-2026-97229 to KEV.
• 1 November 2026: EPSS score checked for this article.
• 2 November 2026: remediation guidance reviewed and published.

Changes log

• 2 November 2026 — r1: Initial publication; records the published CVE date, CISA KEV status and vendor fixed versions.

References

1. GitLab patch release 19.4.2
2. NVD: CVE-2026-97229
3. CISA Known Exploited Vulnerabilities: CVE-2026-97229
4. FIRST EPSS API
5. GitLab issue tracking the remediation