GitLab Shipped a CVSS 10.0 Pre-Auth RCE Fix for Every Self-Managed Release Since 2014. Here's the Upgrade Order, and the Question It Raises.
GitLab released out-of-band patches on October 21 for CVE-2026-110264, a CVSS 10.0 flaw that lets an unauthenticated attacker reach code execution on self-managed instances, reportedly going back to GitLab 7.0 in 2014. GitLab.com was already running the fixed version. Your VPS was not. If you host your own GitLab, this is the week it stops being a hobby server.
What was disclosed
The root cause, according to GitLab's advisory as relayed by AI Weekly, is an integer overflow while compiling a specially crafted regular expression in Onigmo, the Ruby regex engine that GitLab bundles. No login and no user interaction is needed, and the score is the maximum, 10.0.
This is not the first one. A separate flaw, CVE-2026-97229, also scored 10.0 and was patched on October 12. That fix does not cover this bug, so a box that was patched nine days ago is still exposed. Reporting also says the same researcher, who goes by joaxcar, has now found four code-execution bugs in the regex layer in about a month. I take that as a signal about where GitLab's attack surface is thin, not a coincidence.
What I could and could not confirm
The CVE, the score, the October 21 patch date and the cause line up across multiple outlets. Two other details do not line up cleanly. The fixed version numbers differ between sources, one listing 19.4.3, 19.3.6 and 18.11.13, another also listing 19.5.1 and older branches, so I am not going to hand you a table. Look up your own branch on GitLab's release page and take the newest patch for it.
Exposure counts are also soft. One report cites more than 2,700 internet-exposed GitLab CE instances tracked by Shadowserver. I would read that as a rough order of magnitude. CISA's known-exploited catalog did not list the bug as of October 22, and GitLab has not described active exploitation. That is the window where you get to patch on your own schedule instead of an attacker's.
The upgrade order for one box
Assume you run a single-node Omnibus install, which is what most one-person setups are. Here is how I would run it.
Take a snapshot of the VPS or at least a full GitLab backup first. Reporting on this release says versions in the fix line include mandatory database migrations that can mean hours of downtime on a single node, which is the wrong moment to learn that your last backup was in August.
If you are several minor versions behind, do not jump straight to the newest release. GitLab upgrades follow required stops, and skipping one is how a patch night becomes a restore night. Check the upgrade path tool on GitLab's docs for your starting version.
Run the upgrade, wait for background migrations to finish, and then check that CI jobs, your runners and any webhooks still work. If the instance is public, look at the web server logs around Org-mode rendering and sudden HTTP 500 spikes. GitLab published detection hints that include unexplained crashes of the native regex worker.
If you cannot patch tonight, restrict access. Put the instance behind a VPN or an IP allowlist, and make public repositories private if you can. One report says GitLab offers no interim workaround, and the same report lists network restriction as a way to reduce risk, so treat it as a stopgap and not a fix.
The question it raises
Here is the part I care about as someone who builds alone. The VPS costs $6 a month. The real price of self-hosting a forge is the Wednesday you have to drop what you are doing, read an advisory, schedule downtime and hope the migration finishes. Twice in ten days, in this case.
I would ask myself three questions. Does this instance hold anything GitHub or a hosted tier could not? Do I need self-hosting for compliance or control, or did I set it up because it felt like the grown-up move? And if my instance were compromised, what would the attacker get, my source, my deploy keys, my CI secrets?
That last one is the expensive answer. A forge usually holds the keys to everything downstream. If it is popped, rotating credentials across every project is a multi-day job on top of the cleanup.
Where my argument is weaker
Self-hosting has real advantages that a CVE does not erase. You control the data, you avoid per-seat pricing, and you do not depend on a vendor's terms of service. Some clients require it. A hosted GitLab tier also has its own risks, since the vendor sees your code and one compromise there is shared by everyone.
And one more thing in fairness: GitLab shipped a fix within the disclosure window and had already patched its own hosted service. The process worked. The cost landed on the people running the software themselves, which is the trade you accepted when you chose to host it.
What I'd actually do
If you are running self-managed GitLab today, patch it this week, in the order above, and set a calendar reminder to check security releases every Wednesday. If your usage is repositories plus basic CI, I would move to a hosted forge and spend the saved hours on things that make money. If you keep self-hosting, put it behind a VPN so the next 10.0 is a scheduled task, not a race.
Either way, write down where your forge's secrets are before you need to rotate them.
Author
Lukas
@lukcombinator