Fix guides / Security notices

Security notice

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

Last updated: Friday, October 23, 2026, 10:20 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, 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

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. (Konfirmity, Hacker Posts) That can change quickly with a flaw this serious, so update now rather than wait.

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. (Konfirmity, The Hacker News)

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.