CVE-2026–97229: CISA Confirms Active GitLab RCE Exploitation

How a CVSS 10.0 vulnerability exposed a hidden security risk in CI/CD infrastructure — and what engineering teams must verify beyond application upgrades.

On October 29, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026–97229, a maximum-severity GitLab vulnerability, to its Known Exploited Vulnerabilities (KEV) catalog.

The flaw carries a CVSS 10.0 Critical rating and can potentially allow remote code execution on affected GitLab servers through specially crafted regular expressions in CI/CD configurations.

But the most important lesson comes from a real-world incident involving Alpine Linux.

Despite upgrading its GitLab application, Alpine Linux discovered that its server remained vulnerable because its custom container used an unpatched Ruby runtime.

The incident highlights a critical security gap:

Updating an application does not necessarily secure the underlying dependencies it relies on.

Let's examine what happened, how the vulnerability works, and what organizations should do to secure their GitLab infrastructure.

1. Understanding CVE-2026–97229

GitLab is more than a source code repository.

Organizations use it to manage software development, automate builds and testing, coordinate deployments, and manage sensitive CI/CD configurations.

A compromised GitLab server can therefore represent a significant risk to the software delivery environment.

What is the vulnerability?

CVE-2026–97229 is an integer overflow or wraparound vulnerability (CWE-190) affecting GitLab's CI/CD regular expression compiler.

GitLab uses regular expressions to evaluate certain rules and conditions in CI/CD configurations.

The underlying problem exists in Onigmo, the regular expression engine used by Ruby.

Under specific conditions, a specially crafted regular expression can trigger an integer overflow during compilation, resulting in memory corruption and potentially arbitrary code execution.

GitLab assigns the following CVSS v3.1 vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This indicates a network-accessible vulnerability with low assessed attack complexity, no required privileges or user interaction under the vendor's scoring, and potentially high impact on confidentiality, integrity and availability.

Is exploitation completely unauthenticated?

GitLab classifies the issue as potentially allowing unauthenticated remote code execution under certain conditions.

However, independent testing by Rapid7 identified a prerequisite in its demonstrated exploit chain.

The attacker needed a way to introduce a malicious .gitlab-ci.yml configuration and a specially formed repository path into a public project.

On self-managed GitLab instances that permit user self-registration and public project creation, an ordinary newly registered account can satisfy that prerequisite.

This distinction matters.

A CVSS 10.0 rating does not mean every GitLab installation can be exploited through exactly the same conditions.

Actual exposure depends on the affected version, deployment configuration and available attack path.

2. How the Vulnerability Works

The problem involves how regular expressions are validated, compiled and subsequently evaluated.

Rapid7 reproduced the vulnerability against the official GitLab 19.4.1 Community Edition image.

The technical sequence

Step 1 — Malicious CI/CD input

An attacker introduces a CI/CD configuration containing a specially crafted regular expression, using a project and repository path available to the attacker.

Step 2 — Initial validation

The regular expression is initially compiled using a compact US-ASCII representation and passes GitLab's validation.

Step 3 — Recompilation

When the pattern is subsequently evaluated against a specially formed UTF-8 repository path, Ruby's Onigmo engine recompiles it for the new encoding.

Step 4 — Integer overflow

During this process, an integer overflow occurs in the compiler's calculation of the compiled pattern size.

This can generate invalid regular expression instructions and corrupt execution state.

Step 5 — Potential code execution

Rapid7 demonstrated that the resulting control-flow compromise could be used to execute an operating system command under the GitLab git user's privileges.

Rapid7 confirmed successful code execution against GitLab 19.4.1 CE. The same tested input did not execute against the official patched GitLab 19.4.2 CE image.

This is not simply a CI/CD pipeline running a developer-supplied command.

The security issue is that malicious configuration input can affect the GitLab server process itself through the vulnerable regular expression compiler.

That distinction is central to understanding the severity.

3. Real-World Incident: What Happened to Alpine Linux?

On October 28, 2026, Alpine Linux published a detailed report describing an attempted attack against its GitLab infrastructure.

The report provides an important example of both exploitation risk and incomplete patch coverage.

October 20–21: Attack attempts

An attacker registered an account and submitted specially crafted CI configurations to Alpine Linux's GitLab instance.

At the time, the server was running GitLab 19.3.4, which did not contain the relevant October 12 security fix.

The attempts caused eight GitLab worker crashes.

In four instances, the attacker progressed partway through the exploit before failing at a subsequent stage.

The attacker also downloaded Alpine Linux's GitLab container image, suggesting an effort to understand or adapt to the runtime environment.

October 22: Application upgraded

Alpine Linux upgraded to GitLab 19.3.6.

This release was newer than the first GitLab version containing the vulnerability fix.

However, the upgrade did not fully remediate its installation.

October 26: The underlying problem discovered

Alpine Linux identified why its server remained vulnerable.

The GitLab security fix depended on changes to Ruby's Onigmo engine.

GitLab's official packages included patched Ruby components, but Alpine Linux's custom container used a separately maintained Ruby installation.

That runtime did not yet contain the required fix.

Consequently, the GitLab application had been updated while its underlying Ruby component remained vulnerable.

October 27–30: Recovery and rebuilding

Alpine Linux restricted access and rebuilt its GitLab environment using patched components.

On October 30, it announced that the service had reopened on a rebuilt server running GitLab 19.3.7 with Ruby 3.3.13.

Was the server actually compromised?

Alpine Linux found no evidence that the attacker successfully executed code.

It also reported no evidence that the examined repositories, packages or releases were modified.

However, some relevant logs were no longer available, and outbound network activity had not been comprehensively recorded.

As a result, the team could not conclusively rule out successful exploitation and treated the environment as potentially compromised.

The decision to rebuild was therefore a precaution based on unresolved forensic uncertainty — not proof of a confirmed successful attack.

The key lesson: A newer application version is not proof of a secure deployment if separately managed runtime dependencies remain unpatched.

4. Why This Matters Beyond GitLab

This vulnerability exposes several broader risks in modern software delivery infrastructure.

4.1 Application dependencies can preserve vulnerabilities

Applications depend on programming runtimes, frameworks, libraries and system packages.

A vendor may ship fixes within its official distribution while custom builds continue using separately maintained components.

The Alpine Linux incident is a concrete example of this difference.

4.2 CI/CD infrastructure holds sensitive access

Depending on its configuration, a GitLab environment may provide access to:

• Source repositories and private project information
• CI/CD variables and credentials
• Runner tokens and service integrations
• Deployment automation and infrastructure connections
• Webhook and repository mirroring credentials

Successful exploitation could expose assets accessible to the compromised server or allow further attacks using its privileges.

These are potential consequences, not a claim that all occurred in the Alpine Linux incident.

4.3 Containers do not guarantee dependency security

A container image can contain a newer application release while retaining vulnerable runtime packages.

Security verification must therefore consider the actual contents of the deployed image, not just its application version or tag.

4.4 Incomplete logs complicate incident response

A patched system may no longer be exploitable, but that does not establish whether an attacker previously succeeded.

Without adequate application, process and network telemetry, teams can face substantial uncertainty when assessing historical compromise.

5. Affected GitLab Versions and Available Fixes

GitLab released the relevant security patches on October 12, 2026.

The affected versions and first fixed releases are:

GitLab 19.2

Affected: 19.2.0 through 19.2.7

First fixed version: 19.2.8

GitLab 19.3

Affected: 19.3.0 through 19.3.4

First fixed version: 19.3.5

GitLab 19.4

Affected: 19.4.0 through 19.4.1

First fixed version: 19.4.2

Both Community Edition and Enterprise Edition are affected.

GitLab reported that GitLab.com and GitLab Dedicated infrastructure had been patched.

Organizations should install the latest appropriate supported GitLab security release rather than treating these first fixed versions as permanent upgrade targets.

What about Ruby?

Ruby's security team confirmed the underlying Onigmo fixes in the following recommended releases:

• Ruby 3.3.13
• Ruby 3.4.12
• Ruby 4.0.9

For CVE-2026–97229 specifically, Ruby 4.0.8 already contained the relevant integer overflow fix, while 4.0.9 incorporates an additional related fix.

Custom GitLab deployments should verify the installed runtime or an equivalent vendor-supported backported patch.

For standard GitLab packages containing the vendor's patched Ruby runtime, a separate upstream Ruby upgrade is not necessarily required.

6. How Organizations Should Respond

A complete response should address exposure, remediation, investigation and recovery.

Step 1 — Identify affected deployments

Inventory all self-managed GitLab installations.

Record the application version, installation method, container image, and Ruby runtime used.

Pay particular attention to source installations and custom-built containers that do not use GitLab's bundled runtime.

Step 2 — Apply the complete security fix

Upgrade affected GitLab installations to the latest suitable security release.

For custom builds, verify that the Ruby/Onigmo security fixes are present.

Confirm the actual deployed container image and runtime components rather than relying on image tags alone.

Step 3 — Reduce exposure until patching is complete

Rapid7 recommends restricting anonymous access to public projects and preventing untrusted users from creating or modifying public projects where this is feasible.

These measures can reduce exposure to its demonstrated exploit path.

However, they are temporary risk-reduction measures, not substitutes for patching.

Step 4 — Investigate exploitation attempts

GitLab published six threat detections for self-managed instances:

1. Onigmo native worker crash
2. GraphQL CI lint hostile regular expression
3. Oversized non-ASCII CI regular expression path
4. CI regular expression guard rejection
5. CI lint Workhorse worker crash
6. CI lint scripted client error burst

Security teams should apply GitLab's published detections using the supported log sources and investigate relevant matches.

Unexpected worker crashes and CI lint activity can justify investigation, but they are not individually proof of successful exploitation.

Step 5 — Assess compromise and recover if necessary

Where evidence indicates exploitation, preserve forensic artifacts and activate the organization's incident-response procedures.

Review suspicious processes, access patterns, CI/CD modifications and potentially exposed credentials.

If successful code execution cannot be excluded, assess whether rebuilding affected infrastructure from trusted components is necessary.

Rotate credentials and secrets according to actual or reasonably suspected exposure.

Step 6 — Validate after remediation

A complete remediation review should establish that:

• The GitLab release contains the security fix.
• The deployed Ruby runtime includes the relevant Onigmo correction.
• All affected containers and instances have been updated.
• Relevant historical activity has been investigated.
• Security detections and logging are functioning.
• Repository and CI/CD integrity have been assessed where compromise is suspected.

7. Why CISA's Warning Is Significant

On October 29, 2026, CISA added CVE-2026–97229 to its Known Exploited Vulnerabilities catalog.

The distinction between a CVSS rating and a KEV listing is important.

CVSS 10.0 represents the assessed technical severity of the vulnerability.

CISA KEV inclusion indicates evidence that attackers have exploited the vulnerability in the wild.

The entry specifies a November 1, 2026 remediation deadline for applicable U.S. federal agencies under Binding Operational Directive 26–04.

It also identifies forensic triage as required under that directive.

Private-sector organizations are not automatically bound by the same federal deadline, but the confirmed exploitation makes prompt remediation and investigation important for exposed installations.

8. What DevSecOps Teams Should Learn

CVE-2026–97229 provides three practical lessons that extend beyond the specific GitLab vulnerability.

1. Verify the deployed runtime, not just the application version

Security patches can depend on libraries and runtime components maintained outside the main application's release process.

A fixed application version does not guarantee a separately managed runtime is secure.

2. Treat CI/CD infrastructure as a critical security boundary

Source control, build automation and deployment systems often have access to sensitive organizational assets.

Their compromise can affect the confidentiality and integrity of the wider software delivery lifecycle.

3. Build incident visibility before an incident occurs

Retained logs, process monitoring, network telemetry and independent integrity records are essential when teams need to determine whether an attack actually succeeded.

A vulnerability can be patched relatively quickly.

Establishing confidence in an environment after possible remote code execution can be considerably harder.

Conclusion

CVE-2026–97229 is not merely another critical GitLab security advisory.

It is a documented example of how a vulnerability in an underlying runtime can remain exposed in a custom application deployment even after the application has been upgraded.

The Alpine Linux investigation highlights both the importance of verifying complete patch coverage and the difficulty of recovering confidence when relevant forensic evidence is unavailable.

Organizations should assess the vulnerability across the entire GitLab deployment, apply appropriate fixes, review exploitation evidence and validate the integrity of their CI/CD infrastructure.

A security update is complete only when the vulnerable components in the deployed environment have actually been fixed.

References and Technical Sources

1. GitLab — Critical Patch Release, October 12, 2026 https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/

2. CISA — Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog

3. Alpine Linux — GitLab Security Incident, October 28, 2026 https://alpinelinux.org/posts/GitLab-security-incident-CVE-2026-97229.html

4. Alpine Linux — GitLab Recovery, October 30, 2026 https://www.alpinelinux.org/posts/GitLab-reopened-after-security-incident.html

5. Rapid7 — CVE-2026–97229 Technical Analysis https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/

6. Ruby Security Team — Regular Expression Compilation Fixes, October 23, 2026 https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/

Information verified using official vendor disclosures, independent security research and the affected organization's published incident report as of October 31, 2026.