Exploited GitLab Vulnerability: Is Your Self-Managed Server at Risk?

At a glance - 30 October 2026

This applies to self-managed GitLab only. GitLab says GitLab.com and GitLab Dedicated were already patched when it published the fix on 12 October 2026, so those customers have nothing to install.

CVE-2026-97229 is an integer overflow in GitLab's CI/CD regular expression compiler. In plain terms, a crafted pattern in a pipeline configuration file gets past GitLab's checks and later makes a size calculation go wrong, which can end in the attacker running their own code on the server. GitLab rates it Critical, CVSS 10.0 (network-reachable, low complexity, no privileges, no user interaction).

CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue on 29 October 2026, with a federal due date of 1 November 2026 and a note that forensic triage is required. KEV is CISA's list of vulnerabilities with evidence of real-world exploitation. That due date binds US federal agencies, not UK businesses, but it tells you how CISA rates the urgency.

Information is still developing. We have not established whether CVE-2026-110264 is also in KEV or being exploited, and we have not seen a public account of a successful compromise through either flaw.

Which GitLab versions are affected

GitLab's advisories list two separate critical regular expression flaws. The version ranges differ, which is where people trip up: patching for the first one leaves a gap for the second.

• CVE-2026-97229 (fixed 12 October 2026): affects 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2, in both Community and Enterprise Editions. Earlier branches are not listed as affected by this one.
• CVE-2026-110264 (fixed 21 October 2026): affects everything from 7.0 before 18.11.13, plus 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3 and 19.5 before 19.5.1. GitLab describes it as another integer overflow in regular expression compilation allowing unauthenticated code execution. The Ruby project lists it as an overflow of internal IDs in patterns with many repeats.
• Minimum fixed versions covering both flaws: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 or 19.5.1.
• Latest patch releases, published 29 October 2026: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 and 18.11.14. Versions 19.5.2 and 19.4.4 were skipped and do not exist. That release addresses an unrelated certificate-trust issue, and GitLab's page does not state that it is cumulative, so confirm the fix list for your branch in GitLab's notes before relying on it.
• Our reading, not a vendor statement: if you are on a release older than 18.11, GitLab's pages list no fix for your branch, so plan an upgrade to a supported release.

What attackers need and what we know about exploitation

The CVSS score describes the worst case. Rapid7, which reproduced code execution on an unpatched GitLab CE 19.4.1 image, says the attacker must be able to place a malicious .gitlab-ci.yml file, with a path containing non-ASCII characters, in a repository. On instances that let anyone self-register and create public projects, a brand new account meets that condition. Locked-down instances that only admit trusted staff are harder to reach, though not immune.

Rapid7 also says a public proof of concept exists, and that the same input failed against the fixed 19.4.2. That is a technical demonstration, not evidence of attacks. The evidence of attacks is CISA's KEV listing, plus Alpine Linux's own published account of an attempt against its GitLab server (see below). Rapid7's statement that it saw no confirmed in-the-wild exploitation dates from 13 October and predates both.

KEV does not tell us who was hit, how many were hit or whether any attempt succeeded, and we do not infer that. The entry lists known ransomware campaign use as Unknown.

What to do now

This is for whoever administers the GitLab server, with root or sudo access on the host. If you are not sure whether your organisation runs its own GitLab, ask your development or IT lead; a self-hosted code repository is easy to forget once it has been quietly working for years.

1. Find the version you are running. Sign in as an administrator and look at the version shown in GitLab, or run the read-only command below on the GitLab server. It changes nothing and prints the GitLab version and the Ruby version in use. For Linux package (Omnibus) installs use the first command; for self-compiled installs use the second, from the GitLab installation directory. On Kubernetes or multi-node setups, run it only on a node that runs the GitLab Rails application.
   bashCopy

   sudo gitlab-rake gitlab:env:info

   bashCopy

   bundle exec rake gitlab:env:info RAILS_ENV=production

2. Compare the result with the version lists above. Anything below your branch's minimum fixed version for both CVEs needs upgrading. Do not stop at 19.2.8, 19.3.5 or 19.4.2: those fix CVE-2026-97229 only.
3. Plan the upgrade to the latest patch for your release line. GitLab's 19.4.2 notes say that release includes database migrations, that a single-node instance will have downtime while they finish before GitLab starts, and that multi-node installs can use zero-downtime procedures. Check the notes for your chosen release for the same warning, take a backup or snapshot using GitLab's own upgrade guidance, and schedule a window. A short outage is the cheaper option here.
4. Until the upgrade is done, reduce the way in. Rapid7 suggests restricting anonymous access to public projects and stopping untrusted users from creating or writing to public projects. If open self-registration is enabled and you do not need it, turning it off is sensible too. Treat all of this as a stopgap: GitLab lists no workaround, and these measures only block the delivery route Rapid7 demonstrated, not the vulnerable code.
5. After upgrading, confirm the new version in the Admin area or by running the version command again. Then, if you manage your own Ruby, check it as described in the next section.

If you build GitLab yourself: check Ruby too

The underlying bug sits in Onigmo, the regular expression engine inside Ruby. The Ruby project published fixes on 23 October 2026 in Ruby 4.0.9, 3.4.12 and 3.3.13. It says applications are only exposed if they compile regular expressions from attacker-controlled text, and that Regexp.timeout and pattern-length limits do not reliably protect against these bugs. Ruby's advisory does not list affected versions explicitly and does not distinguish GitLab package types.

Alpine Linux's incident report adds the practical consequence: in its account, GitLab applies the Ruby fix in its own packages, so a GitLab built from source or run from a container image with standard Ruby can stay vulnerable even on a fixed GitLab version. Alpine found exactly that after upgrading to 19.3.6. We have not independently verified how GitLab's packages carry the fix, so treat this as a strong prompt to check rather than a settled rule.

If you use the official GitLab Linux packages or GitLab's own images, upgrading GitLab is the supported route. If you use a self-compiled install or your own image, the Ruby version printed by the earlier command should be 3.3.13, 3.4.12, 4.0.9 or later. If it is not, upgrade Ruby as well as GitLab, then restart the services. If you use a third-party GitLab image, check the image maintainer's notes: Alpine says its own image tag was republished on 27 October 2026 and that earlier pulls are vulnerable.

Was the server already hit? Patching alone does not answer that

A patch closes the door. It does not tell you whether someone walked through earlier, and it will not remove anything left behind. The window of concern runs from the 12 October fix being public, and the proof of concept appearing on about 13 October, until you actually upgraded.

What to look at first, if you were exposed in that window, especially with open registration:

The questions below are a starting point for the administrator; this is our own engineering judgement drawn from the incident described in the next section, not an official indicator list. GitLab's 19.4.2 notes say GitLab Security released six threat detections for self-managed instances (named in its patch notes) and its 19.5.1 notes list two more. CISA's KEV entry flags forensic triage as required, so if the server is business-critical and you cannot rule out compromise, involve a specialist before you start changing things and keep your logs.

• Accounts created recently by people you do not recognise, and projects or branches containing unfamiliar CI configuration files.
• Sudden GitLab worker crashes, 502 errors or failing CI jobs. Alpine saw all three.
• Outbound connections from the GitLab host that you cannot explain, and anything that looks like a download of your container image from outside your organisation.
• Whether your logs reach back far enough. Alpine said the logs that would have proved or disproved success were no longer available, which is why it rebuilt the server.

What Alpine Linux has said publicly

Alpine Linux published its own account on 28 October 2026. It says an attacker registered an account on its GitLab server on 20 October and sent crafted CI configurations that crashed GitLab worker processes eight times, with four of those getting partway through the exploit before failing at the next stage. The attacker also downloaded Alpine's GitLab container image. Alpine had upgraded to 19.3.4 instead of the fixed 19.3.5, then to 19.3.6, which still ran an unpatched Ruby.

Alpine found no evidence the attacker's code ran but said it could not rule it out. It treated the instance as compromised, rebuilt it from scratch, reset all GitLab passwords and replaced GitLab's secret keys. It says its package-signing keys were never stored on that server and that its repositories, packages and recent releases were not tampered with.

That is Alpine's statement about its own server. It does not tell us how widespread exploitation is, and we are not drawing wider conclusions from it. It is a useful case study for a different reason: the upgrade that looked correct on paper was not the one that protected the server.