On 21 October 2026, GitLab released fixes for a critical GitLab vulnerability, tracked as CVE-2026-110264 and rated 10 out of 10. It can allow an attacker without an account to run their own code on the server. All versions of GitLab Community Edition (CE) and Enterprise Edition (EE) since 7.0, released in 2014, are affected. Swiss companies and public administrations that host GitLab themselves need to install a patched version.
GitLab is used to store an organisation's source code and to automate its production deployments. A compromised server therefore puts all of the organisation's code at stake. According to the specialist site Inside IT, no attacks had yet been observed as of 23 October 2026. The outlet nonetheless considers it almost certain that this will change quickly.
What does the GitLab vulnerability CVE-2026-110264 allow?
The vulnerability stems from an integer overflow during the compilation of a regular expression, a search pattern in text. According to the record published on 22 October 2026 on cve.org, a crafted regular expression can trigger this overflow. Under certain conditions, an unauthenticated user can then execute arbitrary code on the GitLab server.
The score of 10.0 is the maximum on the CVSS (Common Vulnerability Scoring System) scale, in its version 3.1. The published vector describes an attack carried out over the network, of low complexity, requiring no privileges and no user interaction. The impacts on confidentiality, integrity and availability are all rated high.
What is established, then, is the severity of the vulnerability and the list of affected versions. The precise "conditions" of the attack, however, are not detailed by GitLab. The vulnerability was reported by the researcher joaxcar through GitLab's bug bounty programme on the HackerOne platform.
Which version of GitLab should you install?
GitLab recommends that all self-managed installations upgrade immediately to one of the seven patched versions. The choice depends on the branch already installed, as summarised in the table taken from GitLab's release note.
| Installed branch | Patched version to install |
|---|---|
| 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 |
| Before 18.11 | No fix: migrate to a patched branch |
For this vulnerability, GitLab backported the fix, in addition to its usual versions, to the 18.11, 19.0, 19.1 and 19.2 branches. According to Inside IT, however, no update is offered for versions prior to 18.11.13. An older instance therefore has to change branch, which requires more preparation.
The update is not always seamless. GitLab warns that it includes database migrations, notably in versions 19.4.3 and 19.3.6. On a single server, it causes downtime while the migrations complete. An installation spread across several servers can apply it without interruption, using the appropriate procedure.
Why does exploitation follow a fix so quickly?
A published fix makes the vulnerability public, and that is what speeds up attacks. Inside IT puts it this way: by publishing its fixes, GitLab made the vulnerability known. Attackers now know which software to target and which versions remain vulnerable.
The release note also gives a hint about the area involved. For each branch, it mentions a fix to Ruby's regular expression handling. GitLab keeps the technical details of each vulnerability private for 90 days after the fix, but the vulnerability itself is now known.
The recent PHP case shows how fast things can move. For the PHP2Shell PHP vulnerability, Cloudflare was blocking attack attempts nine hours before the official publication, after the embargo was broken. Nothing of the kind has been reported for GitLab in the sources consulted.
What does not concern GitLab.com
Customers who use GitLab online, without their own server, have nothing to do. GitLab.com is already running the patched version. Customers of GitLab Dedicated, the hosted offering for a single organisation, are protected if they are using versions 19.3.5-internal0 or 19.4.2-internal0, or later.
Only self-managed installations are therefore affected: servers run by companies, public administrations, schools or hosting providers. GitLab specifies that, unless stated otherwise, all installation types are affected, whether the full package, an installation from source code or a deployment via Helm chart.
Eleven other vulnerabilities fixed along the way
The same versions fix eleven other vulnerabilities, two of them rated high. CVE-2026-15723, rated 8.2, allows an existing LDAP account to be taken over when two login settings, OmniAuth SAML and LDAP automatic linking, are enabled together. CVE-2026-112212, rated 7.5, allows a shared cache to be poisoned in order to redirect certain OAuth or OIDC connections to an external server. The nine others are rated medium or low.
What an SME or public administration in Switzerland should do
The first step is to find out who manages the GitLab server and which version it is running. The following steps derive from GitLab's guidance:
- compare the installed version with the table and install the patched version for its branch;
- for a version prior to 18.11, plan the migration to a patched branch;
- on a single server, plan for the short downtime caused by the database migrations;
- if a provider manages the instance, ask them whether they have installed one of the seven patched versions;
- use the two detections published by GitLab to spot exploitation attempts, named "Onigmo native worker crash" and "Org mode render error burst";
- subscribe to GitLab's patch notifications, by email or RSS feed.
These steps are in line with an SME's basic IT security measures, which start with prompt updates.
What we do not know yet
Several points remain open in the sources consulted:
- the exact conditions that make the attack possible have not been published;
- the number of self-managed GitLab instances in Switzerland, and the share still vulnerable, are not known;
- no exploitation had been reported as of 23 October 2026, but the situation may have changed since;
- none of the sources mentions a warning from the Federal Office for Cybersecurity (FOCS) about this vulnerability.
