Public Exploit Released for CVSS 10.0 GitLab Flaw CVE-2026-97229

Rapid7 published a proof-of-concept for GitLab CVE-2026-97229, a CVSS 10.0 flaw; Censys counts 25,766 internet-facing hosts running vulnerable versions.
Table of Contents
    Add a header to begin generating the table of contents

    Rapid7 researchers published technical details and a proof-of-concept exploit for CVE-2026-97229, a maximum-severity GitLab vulnerability, on October 13. Censys counts 25,766 internet-facing hosts running affected versions.

    CVE-2026-97229 Turns a Regular-Expression Bug Into Unauthenticated Code Execution

    CVE-2026-97229 carries a CVSS score of 10.0. It is an integer overflow caused by insufficient regular-expression validation in CI/CD configuration, and it lets an unauthenticated user execute code on the server. The researcher joaxcar reported the flaw through HackerOne.

    It affects self-managed GitLab Community Edition and Enterprise Edition in versions 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. GitLab.com is already patched. The same release fixed three high-severity bugs.

    Inside the Rapid7 Proof-of-Concept

    According to the Rapid7 write-up on GitHub, the exploit embeds an inline comment in a regular-expression quantifier to evade the repeat scanner and the US-ASCII size check. An attacker commits a crafted .gitlab-ci.yml file and a UTF-8 repository path to a public project branch. The CI lint endpoint then triggers a recompilation by Ruby’s Onigmo regular-expression engine, which produces the integer overflow. The result is an ASLR bypass and command execution as the git user.

    Advisory Dates Differ Across Reports

    The Hacker News dates the GitLab advisory to October 12. The proof-of-concept itself appeared on October 13, which means the exploit code reached the public after GitLab had already shipped fixes in all three supported release lines.

    The three fixed releases cover the 19.2, 19.3 and 19.4 lines. Any self-managed instance on one of those lines below the patched point release, 19.2.8, 19.3.5 or 19.4.2, remains vulnerable, and Rapid7’s published write-up gives attackers the exact sequence of steps needed to reproduce the attack against it.

    Censys Finds Nearly 26,000 Exposed Hosts

    Censys reports 25,766 internet-facing hosts and 79,224 web properties running vulnerable versions. About 31% of the 82,454 GitLab hosts it detected remain unpatched. Germany has the most exposed hosts at 6,469, followed by Russia with 4,173 and the United States with 2,927.

    No Confirmed Exploitation Yet

    As of reporting, there is no confirmed in-the-wild exploitation of CVE-2026-97229, and CISA has not added it to the Known Exploited Vulnerabilities catalog. The sources for this story do not describe any attacks that have used the new exploit code.

    GitLab’s Recent Run of Critical Bugs Sets the Context

    GitLab has dealt with serious flaws in recent weeks. A CVSS 10.0 GitLab vulnerability, CVE-2026-85706, saw exploitation probes within hours of its disclosure last month. The company also fixed CVE-2026-90970, a flaw in the GitLab AI Gateway with a CVSS score of 9.9, on October 2.

    The earlier case is the closest precedent: exploitation probes arrived within hours of disclosure for CVE-2026-85706. CVE-2026-97229 now has published exploit code, a pool of nearly 26,000 reachable hosts and a vulnerable code path that requires no credentials.

    The exposure data adds detail. Besides the host count, Censys found 79,224 web properties running the vulnerable versions, which means many instances serve more than one web property. Its 31% unpatched figure applies to all 82,454 GitLab hosts it detected, so roughly one in three of the GitLab servers visible on the internet has not taken the fix. Germany leads the country list ahead of Russia and the United States, which means the largest pool of exposed servers sits outside the US.

    Upgrade Targets and Interim Limits

    GitLab customers running self-managed instances need to upgrade to 19.4.2, 19.3.5 or 19.2.8. For instances that cannot be upgraded immediately, the interim guidance is to restrict inbound access and disable untrusted public project creation, since the attack depends on committing a crafted file to a public project branch. The sources do not say how many of the exposed instances allow untrusted users to create public projects, so the share of hosts reachable through that route is unknown.

    Related Posts