GitLab Critical Vulnerability: What to Do About the CVSS 10.0 RCE
GitLab patched a CVSS 10.0 flaw that allows unauthenticated code execution. We explain which version you need to move to on self-managed servers.
Contents 11
The GitLab critical vulnerability allows code to be executed on the server without authentication and carries the highest score on the CVSS scale: 10.0. GitLab patched the flaw on October 21, 2026. Only self-managed installations (those running on your own servers) are at risk; GitLab.com is already up to date. If your team runs its own GitLab, you should check your version today.
In short:
- The flaw stems from an integer overflow bug in the regular expression (regex) compiler and was rated CVSS 10.0.
- According to the sources, affected versions go back as far as 7.0, which covers roughly 12 years of release history.
- There is no workaround; the only fix is to upgrade to one of 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13.
- GitLab says it has not observed exploitation, but that could change at any moment.
What exactly is the GitLab critical vulnerability?
The root of the problem is a regular expression compiler. There is an integer overflow bug in Onigmo, Ruby's built-in regex engine. GitLab ships this engine embedded and patched inside its packages. That is why the bug shows up not as a separate component on your server but as part of GitLab itself.
An integer overflow means a number exceeds the limit it can be stored in and "wraps around" unexpectedly. Bugs like this can cause the wrong amount of memory to be allocated. If an attacker triggers it in the right way, they can run their own code on the server without any authentication. The CVSS 10.0 score was assigned for exactly this reason: the attack can be carried out remotely, requires no login, and its impact amounts to full system takeover.
Why is the CVE number written two different ways?
There is an inconsistency between the sources. The Hacker News and Mallory use the number CVE-2026-110264. SOC Prime, Help Net Security and some other sources instead refer to CVE-2026-97229, announced on October 12.
We could not reach the official GitLab advisory for the October 21 release, so we cannot say for certain which number is correct. In practice the difference is this: use both numbers when scanning your systems or searching records. The actual action does not change; whichever number it goes by, you need to move to a fixed version. For an exact match, we recommend checking GitLab's own security advisory.
Which versions are affected and which version should you move to?
According to Mallory, affected versions go back as far as 7.0. The fixed versions GitLab has released are:
| Release line | Fixed version |
|---|---|
| 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.11.13, 19.0.10, 19.1.9 and 19.2.9 are backported patches that GitLab released outside its usual release schedule. In other words, even if you are stuck on an older line, a separate patch has been issued for you. If you are on a very old version outside this list, you will first need to upgrade to a supported line.
Who needs to take action?
GitLab.com and eligible GitLab Dedicated tenants are already patched. There is nothing to do on their behalf. The group that needs to act is teams that run GitLab on their own infrastructure: those operating GitLab on their own server, in their own data center or in their own cloud account.
Having applied the October 12 security update does not protect you. According to Mallory, those who made that update also need to upgrade to the versions above.
Is there a workaround?
No, the sources do not mention a workaround or mitigation measure. Restricting access with a firewall may reduce the risk, but that is not a fix; it is only a way of narrowing the attack surface until an upgrade is scheduled. If your GitLab is exposed to the internet, review that first, then move the upgrade up your list.
Is the flaw being exploited?
GitLab reports that it has not observed this flaw being exploited. As of October 22, the flaw is also not in CISA's Known Exploited Vulnerabilities (KEV) catalog. That is good news, but not a reason to relax. For critical flaws that require no authentication, exploit code typically appears within days of a patch being released. Since attacks can be built from the patch diff, a clock starts ticking the moment a patch is published.
GitLab has also released two detection rules to catch possible exploitation attempts. If you have a security monitoring setup, adding these rules provides extra assurance until the upgrade is complete.
How was the flaw found?
According to the CVE-2026-97229 record, the flaw was reported through the HackerOne bug bounty program, and credit goes to researcher joaxcar. This shows that the responsible disclosure process worked: the vendor learned of the flaw before attackers did, and it was announced once the patch was ready. Given the number ambiguity noted above, it is worth mentioning which record this information belongs to.
Is this the only one? What happened before?
No. In August 2026, a separate critical flaw in GitLab's GraphQL layer was also patched. Running your own GitLab means following announcements like these regularly. Because your code repositories, CI/CD pipelines and secret keys all live in one place, a compromised GitLab server puts not just that server but every project connected to it at risk. That is why, as we did for a similar PHP vulnerability, we recommend treating patching not as an "if it happens, we'll do it" task but as a scheduled one.
Frequently asked questions
Do I need to do anything if I use GitLab.com?
No. GitLab.com and eligible GitLab Dedicated tenants are already patched. Only those who run GitLab on their own servers need to upgrade.
I applied the October 12 update. Is that enough?
No. Even if you applied the October 12 security update, you need to upgrade to one of the versions released on October 21.
What should I do if I can't upgrade?
There is no official workaround. Until the upgrade is scheduled, restrict your server's internet exposure with a firewall, add the two detection rules GitLab has released to your monitoring system, and carry out the upgrade as soon as possible.
How do I know whether my server has been attacked?
The detection rules GitLab has released were prepared for exactly this purpose. In addition, review your server logs for unexpected processes, newly created admin accounts and unusual outbound connections. If you find anything suspicious, consider rotating credentials and the secret keys stored in your repositories.
Conclusion
With critical flaws, the biggest risk is saying "we'll look at it later" once the patch is out. If you run a self-managed GitLab, check your version, pick the fixed version that fits you from the table above, and complete the upgrade this week. If you want to set up patch management, backup and monitoring processes on your own infrastructure, or hand that burden off, we at EngerekTech can help.
Sources
