Executive Summary

On October 8th, 2026, GitLab released fixes for a critical vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). Tracked as CVE-2026-97229, the flaw lets an unauthenticated, remote attacker execute arbitrary code on the GitLab server by supplying a specially crafted regular expression in a continuous integration and continuous delivery (CI/CD) configuration. Self-managed GitLab CE and EE versions from 19.1 before 19.2.8, 19.3 before 19.3.4, and 19.4 before 19.4.2 are affected.

GitLab is a widely used DevSecOps platform that hosts source code, pipeline secrets, and deployment credentials. GitLab servers are an established target, and attackers exploited an unauthenticated file read flaw in GitLab as recently as September 2026.

GitLab has not reported exploitation in the wild, and no public proof-of-concept (PoC) is known at the time of writing. Given the unauthenticated network reach of the flaw, the sensitivity of the data GitLab holds, and the history of attacks against GitLab servers, Beazley Security recommends affected organizations apply available fixes as soon as possible.

Affected Systems or Products

Product

Affected Versions

Fixed Versions

GitLab CE and EE 19.4 (self-managed)

19.4 before 19.4.2

19.4.2

GitLab CE and EE 19.3 (self-managed)

19.3 before 19.3.4

19.3.4

GitLab CE and EE 19.1 and 19.2 (self-managed)

19.1 before 19.2.8

19.2.8

Mitigations / Workarounds

GitLab has not published a workaround for this vulnerability. Upgrading to a fixed release is the only remediation, and GitLab recommends upgrading all self-managed installations immediately. GitLab's fix for the 19.1 and 19.2 lines is 19.2.8. GitLab has not published a separate 19.1 release, so 19.1 installations must move to 19.2.8 or a later fixed release. The fixed releases include database migrations. Single-node instances will be unavailable while the migrations complete, and GitLab states that multi-node deployments can upgrade without downtime by following its zero-downtime upgrade procedure.

If patching cannot be immediately applied, the following may help to temporarily reduce risk:

  • Restrict access to self-managed GitLab instances to trusted networks or VPN, starting with internet-facing instances. GitLab has not disclosed how an unauthenticated attacker reaches the vulnerable compiler, so network restriction is the most reliable interim measure.

  • Review recent CI/CD configuration changes, including .gitlab-ci.yml files, for unexpected or unusually large regular expressions.

  • If there is any sign the server has been tampered with, rotate the CI/CD variables, access tokens, and deployment credentials stored in GitLab.

Patches

GitLab has released GitLab CE and EE 19.4.2, 19.3.4, and 19.2.8 for self-managed installations. Upgrade instructions and release details are available in the GitLab critical patch release announcement. GitLab.com already runs the patched version, and GitLab Dedicated deployments require no customer action.

How Beazley Security is responding

Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

If you believe your organization may have been impacted by this vulnerability and need support, please contact our Incident Response team.

Sources