Scan my site freeScan free

Fix guides / Security notices

Security notice

Run your own GitLab server? A stranger could take it over. Update today.

Last updated: Monday, November 2, 2026, 8:12 AM ETStatus: Fix released. No attacks reported yet. Update now.

On October 21, 2026, GitLab fixed CVE-2026-110264, a flaw rated 10.0 out of 10, the highest severity score. GitLab says that under certain conditions it could let someone with no account run their own code on a GitLab server that you or your agency run yourselves. That server usually holds your source code, your client projects and the passwords and keys used to deploy websites. It affects every version back to GitLab 7.0, released in 2014, and there is no official workaround. If you only use GitLab.com, GitLab has already fixed it and you need do nothing. If anyone runs a GitLab server for your business, ask them today whether it is on a fixed version.

Update, November 2, 2026

The threat watchdog Shadowserver said on November 1 that it still sees more than 11,300 GitLab servers vulnerable to the flaw in this notice, and more than 1,000 vulnerable to the October 12 flaw that CISA lists as exploited. If your own GitLab server is not on a fixed release, it may be one of them. Update it today. If you only use GitLab.com, you still need do nothing.

  • What Shadowserver said. In a post on Sunday, November 1, 2026, Shadowserver said: "We are currently tracking over 1000 GitLab instances vulnerable to CVE-2026-97229 (on US CISA KEV) and over 11300 instances vulnerable to CVE-2026-110264 (out of around 39K GitLab instances we see daily)." BleepingComputer reported the same numbers on November 2. CVE-2026-110264 is the flaw in this notice. CVE-2026-97229 is the October 12 flaw described in the updates below. (Shadowserver, BleepingComputer)
  • What the numbers do and do not tell you. They are Shadowserver's own counts of the GitLab servers it can see, and we have not checked how it decides that a server is vulnerable. The post does not say whether the two counts overlap, so do not add them together. It does not say that any of these servers has been attacked. BleepingComputer's report says the 1,000 servers are exposed to "ongoing attacks" on CVE-2026-97229; that is BleepingComputer's wording, not Shadowserver's. (Shadowserver, BleepingComputer)
  • The fixed release Shadowserver points to. Its post links GitLab's 19.5.1 patch release post for patch information. That is the release this notice already lists first. The fixed release for each line is unchanged: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, as in Step 2 below. (Shadowserver, GitLab, October 21 release)
  • CISA's list. CISA KEV catalog still lists CVE-2026-97229, added October 29 with a US federal due date of November 1. CVE-2026-110264 is not in the catalog version dated October 30, 2026, which was the newest when we checked on November 2. (CISA KEV catalog)
  • Attacks on CVE-2026-110264. Neither source reports a confirmed attack through CVE-2026-110264. The attacks BleepingComputer describes are for CVE-2026-97229. That can change, and the October 29 update below reports public code that claims to exploit CVE-2026-110264, so do not wait. (Shadowserver, BleepingComputer)
  • GitLab.com users. GitLab says GitLab.com already runs the fixed version. You need do nothing. (GitLab, October 21 release)

What to do

If your own GitLab server is not on a fixed release, update it today to the newest fixed release for your line: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. If GitLab runs on a Ruby you installed or built yourself, including a source install or your own container image, also update that Ruby to 3.3.13, 3.4.12 or 4.0.9 or later and restart GitLab, as in the October 29 update below. If the server ran a vulnerable version while it could be reached from the internet, ask whoever runs it to run GitLab's detection rules over recent logs, including the ones named in the October 29 (evening) update, and to check it for a break-in. A successful attack may leave no crash. If there is any sign code ran, or you cannot rule it out, treat the server as compromised and rotate the secrets as in Step 4 below. EverThread does not test for this. Our scans check your website from the outside and cannot see your GitLab server, its version or the Ruby it runs on. (GitLab, October 21 release, Shadowserver)

Update, October 29, 2026 (evening)

CISA now lists the GitLab flaw from October 12, CVE-2026-97229, as exploited. If your own GitLab server never got that update, it has a hole that attackers are using. Update to the newest fixed release for your line and check the server for a break-in. If you only use GitLab.com, you still need do nothing.

  • CISA's listing. On October 29, 2026, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog "based on evidence of active exploitation." The due date for US federal agencies is November 1, and the catalog marks "forensic triage required," which means agencies must also check whether attackers got in before the patch was applied. It lists ransomware use as "Unknown." CISA does not say who is attacking, how many servers, or what its evidence is, and it does not say whether the evidence includes the Alpine Linux attempt described in the update below. (CISA alert, CISA KEV catalog)
  • Which flaw this is. It is the flaw GitLab fixed on October 12 in 19.4.2, 19.3.5 and 19.2.8, rated 10.0 out of 10. CISA's catalog describes it as an integer overflow that could let an unauthenticated user run code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. GitLab lists versions from 19.2 up to those fixed releases as affected, so 19.3.4 is not fixed. Earlier versions are not listed for this flaw, but they are affected by the CVE-2026-110264 flaw this notice is about. Singapore's Cyber Security Agency advised administrators on October 14 to update immediately. (GitLab, October 12 release, CISA KEV catalog, Cyber Security Agency of Singapore)
  • The reverse of "Patched on October 12? You still need this one." Installing the October 12 update was not enough for the flaw in this notice. And a server that never got the October 12 update is now exposed to an exploited flaw as well as to this notice's flaw. GitLab's October 21 fixed releases (19.5.1, 19.4.3, 19.3.6 and 19.2.9) are newer than the October 12 ones for the same lines, so install the newest fixed release for your line, as in Step 2 below. (GitLab, October 12 release, CISA KEV catalog)
  • Other products can be affected too. CISA's catalog entry, not its short alert, says "Other products can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue in CI/CD Regular Expression Compiler," and points to Ruby's October 23 fixes (Ruby 4.0.9, 3.4.12 and 3.3.13), described in the October 23 update above. CISA does not name any other product. Ruby says these bugs are reached only when an app compiles a pattern from text an attacker controls. (CISA KEV catalog, Ruby)
  • Attack code is public. The Hacker News reports that the security firm Rapid7 published proof-of-concept code for this flaw on October 13, as described in the update below. We do not link it. (The Hacker News)
  • GitLab.com users. GitLab says GitLab.com is already running the patched version and that GitLab Dedicated tenants were patched before the release. You need do nothing. (GitLab, October 12 release)

What to do

If your own GitLab server was last updated before October 12, treat this as urgent. Update to the newest fixed release for your line (Step 2 below). If GitLab runs on a Ruby you installed or built yourself, including a source install or your own container image, also update that Ruby to 3.3.13, 3.4.12 or 4.0.9 or later and restart GitLab. If your server ran a version from 19.2 before 19.2.8, 19.3 before 19.3.5 or 19.4 before 19.4.2 while it could be reached from the internet, check it for a break-in before you trust it. GitLab published six threat detections for CVE-2026-97229, named "Onigmo native worker crash," "Graphql cilint hostile regexp," "ci regexp oversized non ascii path," "ci regexp guard rejection," "ci lint workhorse worker crash" and "ci lint scripted client error burst." Ask whoever runs the server to run them over recent logs. A successful attack may leave no crash. If there is any sign code ran, or you cannot rule it out, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all build and deploy variables, runner tokens and access tokens, as in Step 4 below. EverThread does not test for this. Our scans check your website from the outside and cannot see your GitLab server, its version or the Ruby it runs on. (GitLab, October 12 release, CISA KEV catalog)

Update, October 29, 2026

An attacker tried a related GitLab flaw on Alpine Linux's own server, and upgrading GitLab alone did not fix it there. If your GitLab runs on a copy of Ruby that you installed or built yourself, update Ruby as well as GitLab. If you run GitLab's own Linux package or official container image, updating GitLab is enough.

  • What Alpine Linux reported. On October 28, Alpine Linux, the Linux distribution project, published an incident report. It says that on October 20 and 21 an attacker tried to exploit CVE-2026-97229 on its GitLab server, "a week after the fix was released." CVE-2026-97229 is a different GitLab flaw from the one in this notice. It is also rated 10.0, and GitLab fixed it on October 12 in 19.4.2, 19.3.5 and 19.2.8. Alpine's server was still on 19.3.4 and did not have that fix. Alpine says a newly registered account sent crafted CI settings that crashed GitLab worker processes 8 times, that in 4 of those crashes "the attacker got partway through the exploit and failed at the next step," and that the attack "came close to working." (Alpine Linux, The Hacker News, GitLab, October 12 release)
  • What Alpine found, and what it could not rule out. Alpine says: "We have found no evidence that it succeeded, but we cannot rule it out, so we treated the instance as compromised and rebuilt it from scratch." Alpine says it found no unexpected files, keys, hooks or processes, and no private data returned to the attacker through any web or API request it can see. It could not be sure because some logs from the attack day are gone and neither Alpine nor its hosting provider logged outbound network connections. Alpine also says its package repository, its packages and its October 21 releases showed no sign of tampering in the checks it ran, and that its signing keys were never on the GitLab server. It reset all passwords and replaced GitLab's secret keys. (Alpine Linux, The Hacker News)
  • Why upgrading GitLab did not fix it. Alpine upgraded to GitLab 19.3.6 on October 22 and found on October 26 that the server was still vulnerable. Alpine says: "The fix isn't in GitLab's own code but in a patch to Ruby, which GitLab applies only in its official packages. Our image used standard Ruby, so it didn't get the patch." Ruby is the programming language GitLab is written in. GitLab's own release notes list the fixes as Ruby patches, for example "Add Ruby regexp program size patch for 3.3 and 3.4" in 19.3.5. We did not find a line in the text of either GitLab patch post, October 12 or October 21, telling people who build GitLab themselves to update Ruby. (Alpine Linux, GitLab, October 12 release, GitLab, October 21 release)
  • The rule from Alpine. "If you run GitLab with your own Ruby (from source or in your own container image) rather than GitLab's packages, upgrading GitLab is not enough: you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later." Ruby released those versions on October 23, with fixes for the bugs behind four GitLab CVEs, including CVE-2026-97229 and CVE-2026-110264. Ruby lists fixes only for the 4.0, 3.4 and 3.3 series. (Alpine Linux, Ruby)
  • Does this apply to CVE-2026-110264, the flaw in the rest of this notice? Our reading is yes. GitLab's October 21 release notes list the fix for it as a Ruby patch too ("Add Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0" in 19.3.6), and Ruby's post lists CVE-2026-110264 among the bugs fixed in 3.3.13, 3.4.12 and 4.0.9. Alpine reported the Ruby problem for CVE-2026-97229 only, and we have not seen GitLab or Alpine say it in so many words for CVE-2026-110264. If you run your own Ruby, update it to be safe. (GitLab, October 21 release, Ruby, Alpine Linux)
  • Who needs the extra Ruby step. GitLab's Linux packages and official container images carry GitLab's patched Ruby, so for them updating GitLab is enough. A GitLab installed from source, or a container image that brings its own Ruby, also needs Ruby 3.3.13, 3.4.12 or 4.0.9 or later. If you use Alpine's alpinelinux/gitlab image, Alpine says to pull 19.3.6 again: the image published on October 27 has Ruby 3.3.13, and any 19.3.6 image pulled before that, and all older tags, are vulnerable. (Alpine Linux)
  • Public attack code exists for CVE-2026-97229. The Hacker News reports that the security firm Rapid7 built a working exploit for CVE-2026-97229 in its lab and published proof-of-concept code on October 13. We do not link it. Rapid7's route needs permission to push code to a public project on the server first, so servers where anyone can sign up and create projects are more exposed. Rapid7 says it does not yet know how the original private report avoids that step. (The Hacker News)
  • Correction: we said no public attack code had been found for CVE-2026-110264. That was true on October 22 and no longer is. Our FAQ below says that, citing Konfirmity and Hacker Posts. Since October 22, several GitHub repositories that claim to exploit CVE-2026-110264 have been listed on exploit-tracking sites. We have not tested any of them, do not know whether they work, and do not link them. We still found no report of a confirmed attack through CVE-2026-110264.
  • CISA lists CVE-2026-97229 as exploited. CVE-2026-110264 is not on the list. CVE-2026-110264 is not in the CISA KEV catalog version dated October 29, 2026, checked October 29. Alpine's report describes an attack attempt on CVE-2026-97229 that Alpine found no evidence succeeded, though it says it cannot rule that out. CISA does not say whether its evidence includes Alpine's report. We know of no report of a confirmed break-in through CVE-2026-110264. (CISA KEV catalog, Alpine Linux)

What to do

Update GitLab to the newest release for your line, as in the steps below. If GitLab runs on a Ruby you installed or built yourself, including a source install or your own container image, also update that Ruby to 3.3.13, 3.4.12 or 4.0.9 or later, and restart GitLab afterwards so the new Ruby is in use. If you run GitLab's own Linux package or official image, that extra step is not needed. If your server ran a vulnerable version and could be reached from the internet, especially if strangers can sign up and create projects, ask whoever runs it to check for the signs Alpine saw on October 21, which were GitLab worker crashes, 502 errors and failed CI jobs, and to run GitLab's detection rules. A successful attack may leave no crash. If there is any sign code ran, or you cannot rule it out, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all build and deploy variables, runner tokens and access tokens, as in Step 4 below. EverThread does not test for this. Our scans check your website from the outside and cannot see your GitLab server or the Ruby it runs on. (Alpine Linux, The Hacker News)

Update, October 23, 2026

Ruby has now fixed the bugs behind this GitLab flaw. If your website or store is built with Ruby, such as a Ruby on Rails site, ask your developer to check it too.

  • What Ruby fixed. On October 23, the Ruby team released Ruby 4.0.9, 3.4.12 and 3.3.13. Ruby says they fix several bugs in its regular expression engine, Onigmo, that GitLab found could be used for remote code execution on GitLab servers. Ruby says specially crafted patterns could corrupt memory while Ruby compiles them. The fixes cover the bugs behind CVE-2026-110264 and three earlier GitLab CVEs: CVE-2026-89078 (a double free) and CVE-2026-93577 and CVE-2026-97229 (integer overflows). (Ruby)
  • GitLab servers: no change. Ruby says GitLab already fixed these issues in its own releases by patching the copy of Ruby it ships. The GitLab advice on this page stays the same. (Ruby)
  • Which websites and apps are at risk. Ruby says the bugs are reached only when an app builds a regular expression (a text search pattern) from text an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile, or by placing it inside a pattern such as /#{input}/. Apps that only use patterns written by their own developers are not affected. Ruby has shown code execution only on GitLab servers and does not say how far the same bugs go in other apps. Only your developer can tell whether your code turns visitor or customer input into a pattern. (Ruby)
  • The usual safeguards do not help. Ruby says Regexp.timeout does not protect against these bugs, and limiting the length of patterns does not reliably protect either, because some can be triggered by short patterns. (Ruby)
  • Your security scanner may not flag it. Ruby has not requested CVE IDs of its own for these fixes, at least for now, and says to track them by GitLab's four CVE IDs, for example in a security scanner. (Ruby)

What to do

If anyone builds or runs a Ruby app for your business, including a Rails website or online store, ask them to upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13 or later. Ruby lists fixes only for the 4.0, 3.4 and 3.3 series. Ruby 3.3 normally gets only security fixes at this stage, and Ruby says 3.3.13 includes these as an exception because GitLab assigned CVEs to the issues. If you cannot upgrade yet, Ruby says to avoid compiling regular expressions from untrusted input. EverThread does not test for this. Our scans check your site from the outside and cannot see which Ruby version your app runs or how its code uses regular expressions. (Ruby)

What happened

GitLab is software teams use to store code and run the automated jobs that build and deploy websites and apps. Many web agencies and small businesses use GitLab.com, which GitLab runs for them. Some run their own copy of GitLab on their own server instead, often called self managed GitLab. Only those servers are at risk. (GitLab)

Who should worry

The GitLab flaw itself is not a problem with your website or online store, and visitors to your site are not at risk from it. It is about the server where your code lives. The Ruby bugs behind it can also affect websites and stores built with Ruby, such as Rails sites, in the narrow case described in the October 23 update above.

Ask about this if any of these are true for your business:

You need do nothing if you only use GitLab.com. GitLab says it already runs the fixed version. GitLab Dedicated customers on 19.3.5-internal0, 19.4.2-internal0 or later also need no action. (GitLab)

What to do now

Do these today.

  1. Ask the question. Send the message below to your developer, agency or IT person. You need a clear yes or no: do you run your own GitLab server for our code, and is it on a fixed version?
  2. Update every GitLab server you run. GitLab recommends upgrading all self managed installations immediately. Include staging, backup and test servers. (GitLab, Konfirmity)
  3. If you run GitLab 18.10 or older, there is no fixed release for your version. You need to move to a supported version, which can take several upgrade steps, so plan it today. (Konfirmity)
  4. Check for signs of an attempt. GitLab published two detection rules for this flaw. Ask whoever runs the server to run them over recent logs. (GitLab)
  5. If the answer is "I don't know", that is not a no. Ask them to check using the steps below.

What to send your developer, agency or IT person

GitLab released fixes on October 21, 2026 for CVE-2026-110264 (CVSS 10.0), which GitLab says could let an unauthenticated user run code on a self managed GitLab CE or EE server. Every version from 7.0 is affected, and there is no official workaround. Servers patched on October 12 (19.4.2, 19.3.5, 19.2.8) are still exposed. Please confirm whether you run any self managed GitLab instance for our business, including staging, backup or test instances, and upgrade each one today to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 for its line. If it is on 18.10 or older, please plan the move to a supported version now. Please also run GitLab's two detection rules for this CVE over recent logs and tell us what you find. Sources: GitLab, GitLab detection rule.

Technical steps

Step 1. Check your version

On a Linux package install:

sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

On Docker:

docker exec <container> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Signed in users can also see the version on the /help page. For the Helm chart, read the app version, not the chart version. (Konfirmity)

Step 2. Install the fixed release for your line

Added October 29: if GitLab runs on a Ruby you installed or built yourself, including a source install or your own container image, also update Ruby to 3.3.13, 3.4.12 or 4.0.9 or later. GitLab's Linux packages and official images already include the patched Ruby. See the October 29 update above.

19.5: 19.5.1. 19.4: 19.4.3. 19.3: 19.3.6. 19.2: 19.2.9. 19.1: 19.1.9. 19.0: 19.0.10. 18.11: 18.11.13. 18.10 and older: no fixed release, upgrade to a supported line. (GitLab, Konfirmity)

GitLab says 19.4.3 and 19.3.6 include database migrations, so a single node server will be down until they finish. (GitLab) Konfirmity notes that the older backports (19.2.9 and below) carry only this critical fix, not the other 11 fixes in the same release, which need 19.3.6, 19.4.3 or 19.5.1. (Konfirmity)

Step 3. Until you can patch

There is no official workaround. GitLab's detection rule suggests reducing public visibility where possible, since the no login attack needs a public project. That narrows the risk but does not close the flaw. (GitLab detection rule, Konfirmity)

Step 4. Look for attempts

Load GitLab's two detection rules, "Org mode render error burst" and "Onigmo native worker crash", from its open source TLDR repository. Then check repositories for oversized TODO lines in .org files:

rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'

GitLab's rule warns that a successful attempt can finish quietly without crashing anything. A crash is a reason to investigate, not proof of a break in. If you find signs that code ran, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all build and deploy variables, runner tokens and access tokens. (GitLab detection rule)

Common questions

Has my business been hacked?

This notice does not mean your business has been hacked. No attacks using this flaw had been reported as of October 22, 2026, it was not on the US CISA list of known exploited flaws, and no public attack code had been found, according to Konfirmity and Hacker Posts. Superseded on October 29: several people have since posted code that claims to exploit this flaw, and an attacker has tried the related flaw CVE-2026-97229 on Alpine Linux's server. See the October 29 update above. (Konfirmity, Hacker Posts) That can change quickly with a flaw this serious, so update now rather than wait. Update, October 29 evening: that sentence is about CVE-2026-110264. The October 12 flaw, CVE-2026-97229, is now on the CISA list; see the evening update at the top of this page. Update, November 2: Shadowserver counts more than 11,300 GitLab servers still vulnerable to CVE-2026-110264 and more than 1,000 to CVE-2026-97229, and it does not say that any were attacked. See the November 2 update at the top of this page.

Can EverThread tell me if I am affected?

No. EverThread checks websites from the outside, the way a browser sees them. We do not scan GitLab servers, so we cannot tell whether yours is on a fixed version or whether anyone has tried this flaw on it. Whoever runs your GitLab server can check that. Our free scan looks at your home page from the outside for other common problems, such as an expired padlock certificate, missing browser safety settings and files that should not be public.

We only use GitLab.com. Do we need to do anything?

No. GitLab says GitLab.com already runs the fixed version. (GitLab)

We updated GitLab on October 12. Are we safe?

No. Those releases fixed a different flaw. You need 19.4.3, 19.3.6 or 19.2.9 or later for those lines. If GitLab runs on your own Ruby rather than GitLab's packages, you also need Ruby 3.3.13, 3.4.12 or 4.0.9 or later (see the October 29 update above). (Konfirmity, The Hacker News)

We never installed the October 12 update. Is that a problem?

Yes. On October 29, CISA listed the flaw that update fixed, CVE-2026-97229, as exploited. A server on a version from 19.2 before 19.2.8, from 19.3 before 19.3.5 or from 19.4 before 19.4.2 is exposed to it, as well as to the flaw in this notice. Update to the newest fixed release for your line, and ask whoever runs the server to check it for a break-in. If you only use GitLab.com, you need do nothing. (CISA KEV catalog, GitLab, October 12 release)

Our website runs on Ruby on Rails. Are we affected?

Only if your app builds regular expressions from text that visitors or customers can control. Ruby says apps that only use patterns written by their own developers are not affected. Ask your developer to check, and to upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13 or later either way. EverThread does not test for this and cannot see your Ruby version from the outside. (Ruby)

Where can I follow official updates?

GitLab's patch release post has the official details. GitLab says it makes the full issue details public 90 days after the fix. (GitLab)

Security alerts by email

Hear about the next one first.

When a flaw puts websites at risk, we send one plain-English email: what happened, who it affects and what to do. It's free, whether or not you use EverThread.

We email you a link to confirm first, and every alert has a one-click unsubscribe. Alerts can include a short note about EverThread. Already a customer? Use your account email and your alerts include a link to your dashboard. Privacy

Sources

While you are here

Check your site's other basics free. We look at your home page the way a browser does and tell you in plain English. This scan does not check GitLab servers for the flaw above. No account.

Or sign up free and we check it every day and email you when something changes.