A public proof-of-concept exploit is now circulating for a maximum-severity GitLab vulnerability, giving organizations running self-managed instances a hard deadline to patch. The flaw, tracked as CVE-2026-97229, carries a CVSS score of 10.0 and allows an attacker to execute commands on a vulnerable GitLab server through a bug in its CI/CD regular-expression compiler.

How the Exploit Chain Works

Researcher Jonah Burgess published the working exploit code, which targets both GitLab Community Edition and Enterprise Edition. GitLab’s own advisory describes the underlying issue as an integer overflow in the CI/CD regular-expression compiler — the component responsible for validating pipeline configuration syntax.

The attack path runs through GitLab’s CI lint endpoint, a feature meant to check CI/CD configuration files for errors before they run. According to the published analysis, an attacker crafts a pipeline configuration containing a regular expression paired with a specially named repository path that includes Unicode characters. That combination causes Ruby to recompile the expression after GitLab’s own size validation has already passed, triggering an integer overflow that redirects the regex engine’s execution into a command-execution function.

Critically, the access bar for triggering this chain is lower than many critical vulnerabilities require. The attacker only needs permission to push a branch to a public project on the target instance — something that’s often trivially available on self-hosted or loosely configured GitLab deployments. From there, a follow-up request to the CI lint endpoint requires no authentication token, session cookie, or other authorization header at all.

What Successful Exploitation Looks Like

Burgess notes that commands triggered through the bug execute under GitLab’s internal git service account rather than as a system administrator — a meaningful limitation, but still enough to give an attacker a foothold for lateral movement, source code access, or further privilege escalation depending on the server’s configuration.

Detecting a successful attempt isn’t entirely straightforward either. The test request typically ends in an HTTP 502 error as the worker process crashes after the injected command runs, which on its own doesn’t confirm exploitation occurred. In Burgess’s testing, confirmation came through command output returned via an external callback channel. The exploit also demands significant server memory to work reliably; under low-memory conditions or concurrent requests, it’s more likely to cause a denial-of-service crash than clean code execution. The published PoC is calibrated specifically against the official GitLab CE 19.4.1 Linux amd64 image, so results may vary against other builds.

Which Versions Need Patching

GitLab’s advisory lists the affected ranges precisely:

• 19.2 before 19.2.8
• 19.3 before 19.3.5
• 19.4 before 19.4.2

Fixed versions were released on October 12, 2026. GitLab.com is already running a patched build, and GitLab Dedicated customers don’t need to take any action. The risk falls squarely on self-managed instances that haven’t yet applied the update.

Recommended Actions

With exploit code already public, GitLab administrators running self-managed instances should move quickly:

• Confirm your installed version against the affected ranges above and upgrade immediately to 19.2.8, 19.3.5, 19.4.2, or later.
• Review recent CI/CD configuration changes across projects, paying particular attention to new or modified regular expressions and unusual branch names containing non-standard characters.
• Audit who has permission to push branches to public projects, since that’s the only access requirement for the first stage of the attack.
• Watch for unexplained 502 errors tied to CI lint requests, which could indicate exploitation attempts in progress.

There’s no confirmed evidence yet that CVE-2026-97229 is being exploited in real-world intrusions. But a maximum CVSS score combined with public, working exploit code and a low bar for initial access is exactly the combination that tends to draw opportunistic attackers quickly. For any organization running GitLab’s CI/CD pipelines in production, this patch shouldn’t wait for the next scheduled maintenance window.