GitLab RCE Hits CVSS 10.0, 7 Branches Patched [2026]

GitLab shipped emergency fixes on October 21, 2026 for GitLab CVE-2026-110264, a maximum-severity flaw in its regular expression compiler that can let an unauthenticated attacker run arbitrary code on a self-managed server. The company backported the patch to seven release branches at once: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1. The CVSS score is 10.0, and the attack needs no login and no user interaction.

Admins who triage by a single number should pause here. Exposure, exploitation status and rebuild speed all shape the response, and the trade-offs are laid out in this look at CVSS versus CISA KEV prioritization . For this bug, the call is easy. Patch first, then investigate.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

GitLab CVE-2026-110264 Lands as a CVSS 10.0 Emergency

The researcher who found it goes by “joaxcar” (Johan Carlsson) and reported it through GitLab’s HackerOne bug bounty program. BleepingComputer notes the same researcher also reported CVE-2026-97229, another 10/10 remote code execution flaw in the CI/CD regular expression compiler that GitLab disclosed ten days earlier. Two maximum-severity scores from one engine in under two weeks is not normal.

Reach is what sets this one apart. CERT.UG, Uganda’s national computer emergency response team, says the vulnerable component has been in GitLab’s codebase since version 7.0 in 2014. That means roughly twelve years of self-managed Community Edition (CE) and Enterprise Edition (EE) releases carry the flaw until patched. GitLab.com already runs the fixed code, so the risk lands on teams that host their own instances.

GitLab 19.5 itself only shipped on October 15, 2026. That left the newest release exposed for six days before 19.5.1 arrived. Anyone who upgraded promptly to chase the new Model Context Protocol (MCP) server features still needed another upgrade.

How the Regex Compiler Bug Works

GitLab’s advisory, as quoted by BleepingComputer, describes the problem in careful terms: “GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression.” In plain language, an attacker supplies a pattern, GitLab’s Ruby runtime tries to compile it, and a number inside the compiler overflows. Memory then goes wrong in a way that can be steered into code execution.

The Ruby core team explains the plumbing. GitLab compiles regular expressions supplied by its users, such as patterns in CI configuration, with Regexp.new . Specially crafted patterns can corrupt memory while Ruby compiles them. For this CVE, the matching Ruby bug is described as an overflow of internal IDs in a pattern with many repeats, tracked upstream as change #16801.

The general shape of this bug family is familiar to anyone who has read compiler security reports. A regex compiler tracks counts, offsets and program sizes in fixed-width integers. Feed it a pattern that forces one of those numbers past its limit, and the value wraps around to something small. The compiler then allocates too little space, or points at the wrong place, and later writes land outside the buffer. The Ruby advisory maps three flavors of that mistake across four CVEs, which hints that the compiler needs a broader audit than any single patch can provide.

Most developers know regex risk as ReDoS, where a nasty pattern burns CPU while matching. This is a different animal. The bug fires while the pattern is being turned into bytecode, before it touches any input. Ruby is blunt the consequence: “Regexp.timeout does not protect against these bugs.” Capping pattern length does not reliably help either, because some of the triggers are short.

What GitLab has not said the entry point. GitLab’s wording, “under certain conditions,” leaves the exact unauthenticated path unstated in the sources I reviewed. The two detection rules GitLab published offer hints. Their names point to crashes in the native regex worker and to bursts of Org-mode render errors, which suggests exploitation attempts may leave noisy traces before they succeed. That is inference, not confirmation, so treat it as a starting point for log hunting rather than a full description of the attack.

Affected and Fixed GitLab Versions

The affected range runs from GitLab 7.0 up to the release before each fixed version. Every one of the seven patched branches also exists as a vulnerable build, so the question for admins is simply which branch they sit on. The table lays out the cutoffs.

The last column matters more than it looks. heise online reported that the four oldest branches received only the critical backport, while the other 11 vulnerabilities are fixed solely in 19.3.6, 19.4.3 and 19.5.1. Teams that want every fix must reach one of those three releases.

GitLab.com is already running the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already include the fixes and need to take no action, according to the advisory text reproduced by BleepingComputer. The exposed population is self-managed CE and EE, and nothing else.

Four GitLab CVEs, Three Ruby Bugs

The Ruby project’s own advisory ties four GitLab CVEs to three underlying bugs in Onigmo, the regular expression engine that Ruby bundles. It reads like a chain of related defects in one parser rather than four unrelated surprises. The table below follows the mapping the Ruby team published on October 23, 2026.

Read down the last column and a practical trap appears. Ruby 4.0.8 contains the fix for the two integer-overflow CVEs but not for CVE-2026-110264. A team that bumped to 4.0.8 last week to close the earlier holes still needs to reach 4.0.9. Ruby 3.4.12 and 3.3.13 carry all three fixes.

CERT.UG calls CVE-2026-110264 the second CVSS 10.0 unauthenticated remote code execution flaw GitLab has patched in nine days. The count gets worse if you include September, when BleepingComputer says GitLab fixed yet another maximum-severity CE and EE bug, CVE-2026-85706. That one leaks credentials and other secrets rather than executing code, which makes it a different class of problem in the same product.

Ruby 4.0.9, 3.4.12 and 3.3.13: The Runtime Fix Behind the Patches

On October 23, 2026, two days after GitLab’s release, the Ruby team shipped Ruby 4.0.9, 3.4.12 and 3.3.13 and published a dedicated advisory. GitLab had already patched the Ruby it ships. The upstream releases bring the same fixes to everyone else who runs Ruby. Ruby 3.3 sits in its security maintenance phase, and the team made an exception to include these fixes because GitLab assigned CVEs to issues that rely on them.

Ruby says an application is exposed only when it compiles a regular expression from attacker-controlled text. The triggers include Regexp.new , Regexp.union , Regexp.compile , and interpolating input into a literal such as /#{input}/ . Applications that use only regular expressions written by their own developers are not affected. If an upgrade is impossible, the team’s advice is to stop compiling untrusted patterns.

Scanners May Miss the Ruby Side

Ruby stated it has not requested CVE identifiers of its own for these fixes, at least for now. My read: scanners that match against GitLab’s product records will flag a vulnerable GitLab package, but they may stay quiet a vulnerable Ruby runtime inside a separate container image or worker. Upgrading GitLab does not automatically update a Ruby install that lives elsewhere. Any internal service that accepts user-supplied patterns, from log filters to rule engines, deserves a manual check.

Is GitLab CVE-2026-110264 Being Exploited?

As of heise’s October 22 report, no attacks exploiting the vulnerability were known. In the sources I reviewed through October 28, I found no confirmed in-the-wild exploitation and no listing in CISA’s Known Exploited Vulnerabilities (KEV) catalog. That could change fast. Reportedly, reproduction material appeared on GitHub between October 23 and 26, and that single-source claim deserves caution until a second outlet confirms it.

History argues against complacency. BleepingComputer says CISA added CVE-2026-85706 to the KEV list one day after GitLab’s September fix and gave federal agencies three days to secure their systems. Since November 2021, CISA has flagged five GitLab flaws exploited in the wild, including one used in ransomware attacks. The pattern with other infrastructure software is similar, as the VMware vCenter remote code execution flaw now tied to ransomware showed once attackers had working code.

The absence of confirmed exploitation is a weak comfort. Patch diffs and Ruby’s public change references give skilled attackers a map of the bug within days. Defenders should assume the window between disclosure and weaponization is already closing.

Picture the attacker’s playbook, as an analyst would sketch it rather than as a confirmed report. First comes scanning for GitLab login pages and version strings. Then a malformed pattern goes to whichever endpoint compiles it. A successful hit gives code execution as the GitLab service account, and from there the attacker can read repository data, harvest CI variables and plant a persistent job in a pipeline. Each step is routine tradecraft against forges, which is why a single memory-corruption bug can turn into a full supply chain incident within hours.

How Many GitLab Servers Are Exposed

Shadowserver, an internet scanning watchdog, tracks more than 2,700 GitLab Community Edition instances reachable online, according to BleepingComputer. Shadowserver does not say how many are honeypots or already patched, so the figure sets an upper bound on public exposure rather than a count of vulnerable servers. It also covers CE only. Enterprise Edition hosts, which skew toward larger organizations, sit outside that number.

TechTarget’s report framed the stakes bluntly: every release since 2014 is affected. BleepingComputer adds that GitLab counts over 30 million registered users and that more than half of the Fortune 100 use the platform, including Nvidia, T-Mobile, Lockheed Martin, Airbus and Goldman Sachs. Those are customer claims as relayed by the outlet, but they explain why security teams treat a GitLab bug as a supply chain problem.

Internet exposure is not the only risk. Plenty of instances sit behind a VPN or an internal network, where a single compromised laptop or contractor account is enough to reach them. For those servers, “not internet-facing” lowers the priority a notch but does not remove the need to patch this week.

The 11 Other Vulnerabilities in the Same Release

The October 21 release fixed 12 security issues in total. The CERT-EU advisory confirms the split of two high, five medium and four low alongside the one critical, which makes it a useful second source. The breakdown below follows the heise report.

Two of the high-severity items deserve attention from identity teams. CVE-2026-15723 lets an authenticated user take over another person’s LDAP account without any action from the victim, provided OmniAuth-SAML and LDAP Auto-Linking are both enabled. CVE-2026-112212 lets an unauthenticated attacker manipulate the OAuth and OIDC discovery document in a shared cache, redirecting certain OAuth flows to a server the attacker controls. Neither matches the severity of the regex bug, yet both touch authentication, which tends to be where attackers pivot .

Market Impact: Why Self-Managed DevSecOps Teams Feel It

A GitLab server holds source code, CI variables, deploy keys, runner registrations and often production credentials. Owning it hands an attacker the keys to the build pipeline. That is the supply chain argument, and Aviatrix’s threat research team makes it directly: CI/CD infrastructure has become a primary attack surface, and patching alone is not enough.

The commercial angle is awkward for GitLab. The company announced its “governed software factory” capabilities on October 6, 2026 and shipped GitLab 19.5 with MCP server general availability on October 15. Six days after that release, customers were scrambling to patch a parser flaw that dates to 2014. Hosted GitLab.com customers skipped the scramble because that fleet already ran the patched version when the advisory went out, which strengthens the case for managed offerings such as GitLab Dedicated.

Other CI platforms have drawn the same attention. Attackers went after exposed build servers in the TeamCity ransomware campaign , and a GitLab instance offers the same prize. Expect enterprise buyers to ask harder questions patch cadence, backport policy and detection tooling in their renewal cycle. I would not expect a mass exodus from self-hosting, because many regulated teams cannot move to SaaS, but I do expect more budget for virtual patching and network segmentation around forges.

Security leaders also face a communication task. Boards and auditors tend to hear “CVSS 10.0” and ask whether the company was breached. The honest answer needs three parts: which instances ran vulnerable builds, when each one was patched, and what log review showed. Teams that keep an accurate asset inventory can answer in an afternoon. Teams that discover forgotten test servers during the response will spend days, and that gap is where the real cost of a flaw like this accumulates.

Vendors that sell scanning and attack surface tools will use the episode in their pitches, and some of the pitches will be fair. A Ruby runtime inside a container image is exactly the kind of buried dependency that software composition analysis exists to find. The test for any such product is simple: does it flag a vulnerable Ruby patch level when no Ruby-specific CVE exists yet?

Historical Context: GitLab’s Run of Critical Bugs

The October 21 release did not arrive in a vacuum. The sequence over the past weeks, drawn from BleepingComputer, CERT.UG and the Ruby advisory, looks like this:

September 2026: GitLab fixes CVE-2026-85706, a maximum-severity CE and EE flaw that lets unauthenticated attackers read secrets. CISA adds it to KEV a day later with a three-day deadline for federal agencies.

ten days before October 22: GitLab warns of CVE-2026-97229, a CVSS 10.0 remote code execution bug in the CI/CD regular expression compiler.

October 21: GitLab backports the CVE-2026-110264 fix to seven branches.

October 23: Ruby releases 4.0.9, 3.4.12 and 3.3.13 with the underlying engine fixes.

Newer GitLab components are drawing scrutiny as well. A recent GitLab AI Gateway flaw reached CVSS 9.9 without a known exploit. The common thread is a fast-moving product surface with older code underneath. Regex handling that survived a decade of reviews now faces closer scrutiny from researchers, and four CVEs in a few weeks suggest they are finding real material.

How GitLab’s Response Compares With Other Self-Hosted Platforms

On process, GitLab scores well. The SaaS fleet already ran the fix, the team backported across seven branches in one day, credited the finder, and published two detection rules for self-managed admins. CERT.UG notes that this wide backport is a step the company reserves for its most severe issues. Many vendors patch only the latest branch and leave older customers to upgrade under pressure.

The wider market has seen similar maximum-severity scares. Dell’s CSM software also drew a perfect score, covered in the Dell CSM flaw on Kubernetes , and N-able’s N-central product faced a CVSS 10.0 remote code execution flaw that needed repeated fixes.

Open-source AI tooling lands in the same bucket, with a Langflow remote code execution bug on the list of recent critical disclosures. Where GitLab differs is the shared-component story. A bug in a bundled regex engine ripples to every Ruby project that compiles untrusted patterns, and Ruby’s decision to hold off on CVE identifiers makes tracking harder. Most competitors’ flaws sit in their own code, which makes scanning and attribution cleaner. That is a point against the single-vendor assumption many risk registers make.

Patching and Detection Checklist

CERT-EU’s security advisory 2026-019 recommends updating affected assets as soon as possible, prioritizing internet-facing ones, and running an assessment to identify compromised assets. The sequence below turns that into an order of operations.

Inventory every self-managed GitLab CE and EE instance, including test, staging and forgotten hosts.

Upgrade internet-facing instances first to 19.5.1, 19.4.3, 19.3.6 or the fixed release for older branches.

Prefer 19.3.6 or newer so the 11 other security fixes land too.

Run GitLab’s two published detection rules against logs, then review runner and worker crash history.

If you suspect compromise, rotate CI/CD variables, deploy keys, personal access tokens and runner registration tokens.

Upgrade Ruby to 4.0.9, 3.4.12 or 3.3.13 on any other service that compiles user-supplied patterns.

Restrict network access to the GitLab web interface to known ranges until patching finishes.

These commands confirm which build a host runs, and whether any separate Ruby runtime still predates the fixes.

Treat Network Limits as a Stopgap

Allowlisting the web interface buys hours, not weeks. Because the bug fires during pattern compilation, any path that feeds user text into a regex compile can matter, including features behind a login that an attacker obtains from a leaked token. Segmentation reduces the audience. Only the upgrade removes the flaw. The same logic applies to other flaws that reached KEV status, such as the Nextcloud Collabora flaw , which reached the KEV catalog.

Five Predictions for the Few Weeks

A KEV listing becomes likely. Public technical write-ups and a prior GitLab KEV precedent make a CISA addition plausible within weeks. This is my judgment, not a report.

More Onigmo findings surface. Researchers who saw four CVEs from one engine will keep fuzzing the compiler. Expect further advisories for Ruby applications beyond GitLab.

Ruby may request its own CVEs. The team said it had not done so yet. Pressure from scanner vendors and downstream distributors could change that.

Managed GitLab gains ground in procurement. The SaaS fleet escaped the scramble, and Dedicated tenants did too. Vendors will pitch that gap hard.

Teams add “untrusted regex” to code review checklists. Compile-time exposure is easy to miss, and this episode gives security leads an example to cite in the wider security news cycle and internal training.

FAQ: GitLab CVE-2026-110264

What is GitLab CVE-2026-110264? It is a CVSS 10.0 integer overflow in GitLab’s regular expression compiler. Under certain conditions it lets an unauthenticated attacker execute arbitrary code on a self-managed GitLab CE or EE server.

Which GitLab versions fix it? GitLab released 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1 on October 21, 2026. Versions before those on each branch, back to 7.0, are affected.

Is the flaw being exploited? As of heise’s October 22 report, no attacks were known, and I found no confirmed exploitation or KEV listing through October 28. Treat that as temporary.

Does it affect GitLab.com or GitLab Dedicated? GitLab.com already runs the patched version. Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later include the fixes and need no action.

Do I need to upgrade Ruby as well? Only if you run other Ruby code that compiles attacker-controlled patterns. Ruby 4.0.9, 3.4.12 and 3.3.13 carry the engine fixes, and 4.0.8 does not cover this CVE.

Can a regex timeout or a pattern length limit block it? No. Ruby says Regexp.timeout does not protect against these bugs, and length limits do not reliably help because some triggers are short.

Who found the vulnerability? A researcher using the handle joaxcar, Johan Carlsson, reported it through GitLab’s HackerOne bug bounty program.