A GitLab CI/CD regular-expression compiler flaw lets a crafted project configuration lead to operating-system command execution on an affected self-managed server. Rapid7 reproduced the chain on the official GitLab Community Edition 19.4.1 image, with address space layout randomization enabled. The code ran as the GitLab git user. Both Community Edition and Enterprise Edition installations in the affected release branches need a patch.
GitLab rates the flaw at CVSS 10.0. Rapid7 says an attacker must be able to plant a malicious .gitlab-ci.yml and a UTF-8 repository path in a public project. On a self-managed instance that lets strangers register and create public projects, an ordinary new account can meet that condition. GitLab.com has been patched, and GitLab Dedicated customers need no action for this issue.
Public projects supply the entry
The GitLab-authored CVE record calls CVE-2026-97229 an integer overflow or wraparound in CI/CD regular-expression validation. The CVSS vector specifies network access and no privileges; Rapid7’s reproduced route requires project content an attacker can write. As the researchers put it, an attacker must have “a mechanism to plant a malicious CI/CD configuration” before triggering the bug. Open self-registration paired with public-project creation supplies one such route; existing untrusted project writers are another exposure to examine.
The target is the GitLab application worker, a particularly consequential place to gain execution because it processes the same service that hosts source repositories and CI/CD configuration. Rapid7 demonstrated arbitrary operating-system command execution as the git user in a controlled test. Rapid7 reported no confirmed exploitation in the wild as of October 13; upgrade affected self-managed instances urgently.
Rapid7’s code execution occurred in a GitLab application worker rather than a CI runner. An isolated runner does not isolate the GitLab process that compiles the regex; include the application servers in your upgrade inventory. The test ran on official CE 19.4.1 Linux amd64 with address space layout randomization enabled, so ASLR on that tested image did not stop the worker-level command.
Encoding change bypasses regex validation
GitLab first compiles the crafted expression in a compact US-ASCII representation and validates it. Later, matching it against a valid UTF-8 repository path makes Ruby’s Onigmo regular-expression engine recompile for the new encoding. That second compilation occurs after the original validation. An integer overflow in the compiler’s program-size calculation produces invalid instructions, which Rapid7 says can be steered into attacker-controlled Onigmo VM operations and an operating-system command.
Check the running GitLab version against the fixed releases below. Rapid7’s tested route requires both a malicious CI configuration and a UTF-8 path committed to a public-project branch; inspect project write permissions while scheduling the upgrade. Rapid7’s same input executed on official CE 19.4.1 but not on official patched CE 19.4.2. GitLab credits joaxcar with reporting the vulnerability through its bug bounty program in the CVE record, which also specifies the affected versions.
Patch the affected release branches
The GitLab-authored record and Rapid7 list the same first-fixed releases for self-managed CE and EE:
| Running branch | First fixed version |
|---|---|
19.2 earlier than 19.2.8 | 19.2.8 |
19.3 earlier than 19.3.5 | 19.3.5 |
19.4 earlier than 19.4.2 | 19.4.2 |
Check the version actually running on each self-managed instance and schedule an urgent upgrade on the matching branch. Include deployments where registration is closed: an untrusted user who can write a public project’s CI configuration may still satisfy the demonstrated prerequisite. Where you need a short bridge to patching, restrict anonymous public-project access and prevent untrusted users from creating or writing public projects, as Rapid7 advises. Those restrictions reduce the tested delivery route; the upgrade fixes the vulnerable compiler.
Rapid7 said an authenticated vulnerability check for Exposure Command, Vulnerability Management and Nexpose was expected in its October 13 content release. If you use those products, confirm that the check is available in your installed content before relying on a scan, then compare its result with the GitLab version actually running on each instance. An authenticated vulnerability finding helps locate unpatched servers; it is not a record of commands a worker may have run before patching. For that separate question, investigate unexpected public-project changes and server activity during the affected period.
Verify versions and project access
For GitLab operators, the first useful check is the installed CE or EE version against the three fixed floors above. The second is whether an untrusted account can create a public project or write its .gitlab-ci.yml and a UTF-8 repository path. Tighten that project access while upgrading, then confirm the running release is at or above its branch’s fixed version. The expected result is a patched instance, with the demonstrated untrusted public-project delivery route restricted during rollout.
There is no validated production request signature or compromise indicator in Rapid7’s published analysis. Investigate unexpected project content or activity on a previously affected instance as a possible intrusion, including activity before the upgrade.