Critical GitLab vulnerability: how to check and update your server

What happened

On 21 October GitLab released out-of-band security fixes for Community and Enterprise Edition. The main vulnerability, CVE-2026-110264, is rated the maximum CVSS 10.0: under certain conditions an unauthenticated user can execute arbitrary code on the GitLab server. The cause is a flaw in regular expression handling. Details are in the GitLab advisory.

The release fixes 12 vulnerabilities in total. Besides the main one, two more are rated high:

CVE-2026-15723 (CVSS 8.2) — a GitLab user can take over another LDAP-backed account when SAML sign-in and LDAP auto-linking are both enabled.
CVE-2026-112212 (CVSS 7.5) — under certain conditions an outsider can poison a shared cache of OAuth and OIDC settings and redirect some sign-in flows to an external server.

GitLab has not reported any attacks at the time of publication. It has, however, already published rules for finding traces of attempts — see below.

ForestsNet Cloud servers are unmanaged: you update GitLab on your own VPS. Below is how to check and update. If something does not work, write to support and we will help.

Who is affected

Anyone running their own GitLab Community or Enterprise Edition — from the package, in Docker or from source. All versions since 7.0 are affected, so any installation without the 21 October update is. GitLab.com is already patched and its users are not affected.

How to check the version

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION — the version of GitLab installed from the package.
sudo gitlab-rake gitlab:env:info — a detailed summary, the version is under GitLab information.
docker ps --format '{{.Names}} {{.Image}}' — containers: look for gitlab/gitlab-ce and gitlab/gitlab-ee images. The version inside is shown by docker exec <name> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION.

If your version is below the fixed one for your branch (listed at the end), you need to update.

How to update

Make a backup first: sudo gitlab-backup create. It does not include /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json — copy them separately.

The quickest and safest way is to update to the fixed version of your branch: from 19.4 to 19.4.3, from 19.3 to 19.3.6 and so on. The commands below use 19.4.3 as an example, substitute yours.

Debian and Ubuntu: sudo apt update && sudo apt install gitlab-ce=19.4.3-ce.0. For Enterprise Edition — gitlab-ee=19.4.3-ee.0.
AlmaLinux and Rocky Linux: sudo dnf install gitlab-ce-19.4.3-ce.0.el9, with .el8 on version 8 of the OS. For Enterprise Edition — gitlab-ee-19.4.3-ee.0.el9.
Docker: set an exact tag in your compose file, for example gitlab/gitlab-ce:19.4.3-ce.0, and run docker compose pull && docker compose up -d. With the latest tag an old installation can skip a required upgrade stop.
Installations from source are updated following the GitLab guide.

19.4.3 and 19.3.6 include database migrations: a single-server GitLab is unavailable while they run. If your branch is older than 18.11, there is no fix for it: get to 18.11.13 or later through the required upgrade stops, the route is in the GitLab upgrade path guide.

How to look for traces of an attack

GitLab has published two detection rules: Onigmo native worker crash and Org mode render error burst. On a server with packaged GitLab a quick check looks like this:

sudo grep -A200 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log | grep -E 'org-ruby|onig' — worker crashes while handling regular expressions. Any output is a sign of attempts.
sudo grep 'Timeout::Error' /var/log/gitlab/gitlab-rails/exceptions_json.log | grep -c '\.org"' — render timeouts on .org files. Five or more such errors from one address within a few minutes are a sign of attempts.

In Docker the logs are at the same paths inside the container, run the commands via docker exec <name>. Traces in the logs point to attempts, while their absence does not prove there was no attack: a successful one can be quiet. If you find traces, after updating rotate access tokens, runner tokens and secrets in CI/CD variables.

If you cannot update right away

GitLab offers no temporary mitigation for CVE-2026-110264: only the update protects you. If you have to postpone it, close the GitLab web interface to the internet — keep ports 80 and 443 open only to your own addresses.

Fixed versions

The fixes are included in GitLab CE and EE 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13. For the 19.2, 19.1, 19.0 and 18.11 branches GitLab backported only the CVE-2026-110264 fix, beyond its usual schedule. The other vulnerabilities in the release are fixed from 19.3.6 on, so it is worth moving from older branches to a current one.