CISA Adds Critical GitLab RCE (CVE-2026-97229) to KEV Catalog

Executive Summary

A critical vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE), tracked as CVE-2026-97229, is under active exploitation. The flaw allows an unauthenticated, remote attacker to achieve remote code execution (RCE) on a vulnerable GitLab server. The attack is carried out by submitting a specially crafted regular expression within a CI/CD configuration file. Due to confirmed in-the-wild attacks, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026. This action requires U.S. Federal Civilian Executive Branch agencies to remediate the vulnerability and signals a high risk to all organizations using affected GitLab versions. Immediate patching is strongly recommended.

Vulnerability Details

• CVE ID: CVE-2026-97229
• Description: An issue in GitLab CE/EE allows an unauthenticated attacker to achieve remote code execution via a crafted regular expression in a CI/CD configuration.
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• KEV Catalog: Yes (Added October 29, 2026)

The vulnerability resides in the way GitLab's CI/CD pipeline parser handles certain regular expressions. An attacker can submit a malicious .gitlab-ci.yml file to a public project (or a project they can access) that, when processed by the GitLab server, triggers code execution. This provides a direct path to compromising the underlying server that hosts the GitLab instance.

Affected Systems

The vulnerability impacts the following versions of GitLab CE and EE:

• 19.2 up to (but not including) 19.2.8
• 19.3 up to (but not including) 19.3.5
• 19.4 up to (but not including) 19.4.2

Administrators should upgrade to versions 19.2.8, 19.3.5, 19.4.2, or later.

Exploitation Status

CVE-2026-97229 is being actively exploited. The source material describes one incident where attackers targeted an unpatched GitLab instance running on Alpine Linux. They submitted crafted CI configurations that caused GitLab's worker processes to crash repeatedly. While the attackers in this specific instance did not appear to achieve their final objective (e.g., deploying a webshell or backdoor), the activity was treated as a successful compromise, and the maintainers wisely chose to rebuild the system from scratch. This confirms that threat actors are actively scanning for and attempting to exploit this vulnerability.

Impact Assessment

The impact of a successful exploit is critical. An attacker can gain full control over the GitLab server, allowing them to:

• Steal source code, intellectual property, and sensitive secrets (API keys, credentials) stored in repositories.
• Inject malicious code into the CI/CD pipeline, leading to a supply chain attack where all software built by the compromised GitLab instance is tainted.
• Use the compromised server as a pivot point to attack other systems within the internal network.
• Deploy ransomware or cryptomining malware.

Given GitLab's central role in the software development lifecycle, compromising it is a high-value target for any threat actor.

Cyber Observables — Hunting Hints

The following patterns may help identify vulnerable or compromised systems:

Detection Methods

• Version Scanning: Use vulnerability scanners or asset management systems to identify all internet-facing GitLab instances and check if they are running a vulnerable version.
• Log Analysis: Ingest GitLab application and system logs into a SIEM. Create alerts for repeated sidekiq process crashes or errors related to CI/CD pipeline processing.
• File Integrity Monitoring: Monitor .gitlab-ci.yml files in public repositories for modifications containing obfuscated or malicious-looking regex patterns.

Remediation Steps

1. Patch Immediately: The only effective remediation is to upgrade GitLab instances to a patched version (19.2.8, 19.3.5, 19.4.2, or newer) as a matter of urgency. This is a critical patch.
2. Restrict Access: If patching is not immediately possible, restrict access to the GitLab instance at the network level. Limit access to trusted IP addresses and consider taking the instance offline temporarily if it is not business-critical.
3. Assume Compromise: If you were running a vulnerable version that was exposed to the internet, you should assume it may have been compromised. Follow incident response procedures to hunt for signs of intrusion, such as unexpected local user accounts, running processes, or outbound network connections.