CADChain Blog

GitLab Vulnerability CVE-2026-110264: What the CVSS 10 Flaw Means for Engineering Teams and Their Design Repositories | CADChain | CAD DRM & IP

On 21 October 2026, GitLab released a critical patch for CVE-2026-110264, a flaw rated 10.0, the highest possible CVSS score. It lets an attacker who has no account run code on a self-managed GitLab server. Every self-managed Community and Enterprise Edition release from GitLab 7.0, released in 2014, up to the new fixes is affected. Teams that patched for a different 10.0 flaw on 12 October need to upgrade again.
GitLab.com and GitLab Dedicated are already patched. The risk sits with companies that run GitLab on their own servers, which is common in hardware, automotive, defence and other deep-tech teams that want to keep source code and design data in-house. On 22 October, the EU's cybersecurity service CERT-EU issued its own advisory, and the attack surface company Censys counted about 82,000 GitLab hosts visible on the internet.
For engineering companies, a GitLab server is often more than a code store. It holds firmware, PCB projects, CAD macros and automation scripts, simulation setups, sometimes CAD files in Git LFS, and the CI/CD secrets that connect it all to cloud accounts, PDM and PLM systems. Here is what GitLab fixed, who is exposed, and what engineering managers and security teams should do this week.
TL;DR: GitLab CVE-2026-110264, critical patch of 21 October 2026

An integer overflow in GitLab's regular expression compiler lets an unauthenticated user execute code on self-managed GitLab servers. It is rated CVSS 10.0 and affects versions back to 7.0. Fixed releases: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. As of 22 October, Censys was not aware of exploitation in the wild and no working public exploit had been confirmed. What to do: upgrade now, even if you patched on 12 October, check for signs of compromise, rotate secrets if anything looks wrong, and make sure your most valuable design files stay protected even if a repository server is breached.

What did GitLab fix on 21 October 2026?

The GitLab critical patch release of 21 October 2026 covers twelve vulnerabilities. The critical one, CVE-2026-110264, is described by GitLab as an integer overflow in the regular expression compiler that could allow an unauthenticated user to execute arbitrary code on the server via a specially crafted regular expression. It was reported through GitLab's HackerOne bug bounty programme.
GitLab's advice is direct: "we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately." The other eleven fixes are rated two high, five medium and four low. Four matter for engineering teams that use GitLab to control access and change approval:
  • CVE-2026-15723 (high, 8.2). With OmniAuth SAML and LDAP auto-linking both enabled, an authenticated user could take over an existing LDAP-backed account.
  • CVE-2026-112212 (high, 7.5). An unauthenticated user could poison a shared cache of OAuth and OpenID Connect discovery documents and redirect certain sign-in flows to an external server.
  • CVE-2026-14288 (low, 3.1). A user could bypass a required approval policy on a protected branch, the kind of rule many teams use as a sign-off gate for firmware and design changes.
  • CVE-2026-103515 (low, 2.7). A group Owner could re-enable AI-backed data egress to a third-party service after an administrator had locked it.

Why do teams that patched on 12 October need to patch again?

Nine days earlier, on 12 October 2026, GitLab fixed CVE-2026-97229, another critical flaw rated 10.0. That one was in the way GitLab validated regular expressions in CI/CD configurations, and it affected the 19.2, 19.3 and 19.4 release lines. The fixed versions from that day, 19.4.2, 19.3.5 and 19.2.8, are still vulnerable to the new flaw.
Two separate bugs need two separate fixes. An administrator who upgraded in mid-October has not closed CVE-2026-110264. Only the 21 October releases, or later ones, do.

Which GitLab versions are affected and which ones fix the flaw?

The table shows GitLab's affected ranges for CVE-2026-110264 and the first fixed release for each line. Find your version under Admin, then Help, or with the gitlab-rake gitlab:env:info command on the server.
Release lineAffectedFixed releaseNote
19.519.5.019.5.1Current line
19.419.4.0 to 19.4.219.4.319.4.2 fixed only the 12 October flaw
19.319.3.0 to 19.3.519.3.619.3.5 fixed only the 12 October flaw
19.219.2.0 to 19.2.819.2.919.2.8 fixed only the 12 October flaw
19.1 and 19.0Before 19.1.9 and 19.0.1019.1.9 or 19.0.10Backport releases
18.11 and older7.0 to 18.11.1218.11.13Older lines must follow GitLab's upgrade path
GitLab.com and DedicatedNot affected nowAlready patchedNo action for GitLab-hosted service
The patch includes database migrations. GitLab says single-node installations should expect downtime while migrations run, while multi-node installations can use zero-downtime upgrade procedures. Censys found that more than half of internet-facing GitLab servers run a release line more than seven months old, which gets no fix of its own, and more than a quarter are three or more major versions behind. Those servers have to step through GitLab's required upgrade stops, which takes planning.

Is CVE-2026-110264 being exploited?

Not as far as was publicly known on 22 October. Censys said it was not aware of exploitation in the wild, and the US cybersecurity agency CISA's assessment on the vulnerability record listed exploitation as none. GitLab has withheld the full exploitation details while administrators patch.
That window may be short. Censys reported that two GitHub repositories labelled with the CVE appeared on 22 October; one was deleted and the other emptied. Further repositories claiming proof-of-concept code were reported afterwards, and we could not confirm that any of them is a working exploit. Censys's reading of GitLab's detection guidance is that the flaw sits in the rendering of Org-mode text files and that an attacker needs only one public project that can hold a crafted file. Instances that allow public projects or open sign-up are therefore likely to be the most exposed.
For EU teams, CERT-EU's security advisory 2026-019 is clear on priorities: "CERT-EU recommends organisations to update affected assets as soon as possible, prioritising internet facing assets." It also advises an assessment to find compromised systems.
A patched server is good. A protected file is better. CADChain encrypts CAD files and controls who can open, edit, print or export each one, so a copy taken from a breached server stays locked.

👉 See how CADChain works

What could an attacker reach on an engineering team's GitLab server?

According to Censys, code run through this flaw executes on the server as the git user. From there, an attacker can reach the instance secrets in the gitlab-secrets.json file, all CI/CD variables, runner and access tokens, and read and write access to every repository on the instance.
On a typical deep-tech or hardware team's server, that means:
  • Design data. Firmware source, FPGA and PCB projects, CAD automation scripts and macros, simulation models and, for teams that use Git LFS, CAD files and drawings themselves.
  • Keys to other systems. CI/CD variables often hold cloud credentials, PDM or PLM API tokens, code signing keys, package registry tokens and supplier portal logins.
  • The build pipeline. With write access, an attacker could change code or build scripts, which means products built later could carry changes nobody approved.
  • The record of who did what. Commit history and approvals are evidence of who created which design and when. Write access to the server puts the integrity of that record in question.
This is the same pattern we described this week in our analysis of an AI supply chain attack through a malicious pull request into CAD and PLM toolchains, and in the PHP vulnerability that engineering teams had to patch to protect portals and CAD files. It also echoes the Oracle Agile PLM vulnerabilities in the October 2026 patch update: the systems that store and move engineering data are now a primary target. State-backed groups know it too, as the joint advisory on China-linked hackers for hire targeting manufacturing showed, with old, unpatched vulnerabilities among their favourite ways in.

Does the EU Cyber Resilience Act matter here?

It can. Since 11 September 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities in their products and severe incidents that affect the security of those products. GitLab is a tool, not your product, and a flaw in it is GitLab's to report. But if the server that builds your firmware is compromised and that could affect the security of a product you ship, your own reporting duty may come into play. Our guide to Cyber Resilience Act reporting for CAD, software and hardware makers explains the deadlines and who must report what.

What should engineering teams do now?

  1. Find every GitLab instance. Include test servers, old project servers, labs and instances set up by contractors. The forgotten one is usually the oldest.
  2. Upgrade to a 21 October release or later. 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. A 12 October version is not enough. Plan the upgrade path and downtime for old release lines.
  3. Reduce exposure while you plan. Restrict public projects and open sign-up, and keep the server behind a VPN or allow-list where you can. This lowers risk but does not replace the patch.
  4. Check for signs of compromise. Run GitLab's two published detections and look for the indicators Censys lists: unexpected child processes of Puma, new files owned by the git user in /tmp, and changed crontabs or SSH keys for the git user.
  5. Rotate secrets if anything looks wrong. Treat the instance as compromised and rotate CI/CD variables, runner and access tokens, signing keys and the cloud, PDM and PLM credentials stored there.
  6. Check recent changes to protected branches. Compare firmware and design commits since early October against approvals, and rebuild release artefacts from known-good sources if in doubt.
  7. Protect the files themselves. Keep master CAD files and drawings in a system with file-level encryption and access control, so a stolen repository copy does not mean a stolen design.
  8. Write it down. Record when you patched, what you checked and what you found. That record helps with CRA reporting, insurers and any later dispute.
For background, see our guides to CAD file version control and security best practices, third-party software vulnerabilities in CAD workflows, the difference between CAD file encryption and access control, how to audit CAD file access and how ransomware targets engineering firms. If design data was taken, our article on the legal framework for CAD trade secret protection explains why records of reasonable protection steps matter, and the guide to tamper-proof CAD audit trails with blockchain shows how to keep an access history that a compromised server cannot rewrite.

How does this fit the bigger picture?

Our sister sites covered other developments this week that touch the same question: who controls engineering data, and on what terms.

Conclusion

CVE-2026-110264 is about as serious as a vulnerability gets: no login needed, a perfect 10.0 score and twelve years of affected versions. As of 22 October there was no confirmed exploitation, and GitLab has kept the details back, but that will not last. Any team that runs its own GitLab should be on a 21 October release or later, and teams that patched on 12 October should not assume they are done.
The bigger lesson is that repository and build servers now hold the crown jewels of many engineering companies, from firmware to the files that describe a product. Patching closes one door. Encrypting the most valuable files, controlling who can open them and keeping a record that cannot be rewritten makes sure the next open door does not hand over your designs.
Keep your designs safe, even when a server is not. CADChain gives engineering teams file-level encryption, per-file permissions, access logs and blockchain proof of ownership for CAD files, across CAD systems.

👉 Protect your CAD files with CADChain

FAQ: GitLab CVE-2026-110264

What is CVE-2026-110264?

It is a critical vulnerability in self-managed GitLab Community and Enterprise Editions, rated CVSS 10.0. An integer overflow in the regular expression compiler could let an unauthenticated user execute arbitrary code on the GitLab server. GitLab fixed it on 21 October 2026.

Which GitLab versions fix CVE-2026-110264?

GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, released on 21 October 2026, or any later release. Versions from 7.0 up to those releases are affected.

I patched GitLab on 12 October. Am I safe?

No. The 12 October releases (19.4.2, 19.3.5 and 19.2.8) fixed a different critical flaw, CVE-2026-97229, and remain vulnerable to CVE-2026-110264. You need a 21 October release or later.

Is GitLab.com affected?

No action is needed for GitLab.com, which already runs the patched version. GitLab Dedicated tenants on the patched internal versions are also covered. The risk is for self-managed installations.

Has CVE-2026-110264 been exploited?

As of 22 October 2026, Censys was not aware of exploitation in the wild and CISA's assessment listed exploitation as none. Repositories claiming proof-of-concept code have appeared, but we could not confirm a working exploit.

How do I know if my GitLab server was compromised?

Run GitLab's two published detections and look for unexpected child processes of Puma, new files owned by the git user in /tmp, and changed crontabs or SSH keys for the git user. If you find any, treat the server as compromised and rotate its secrets.

Why does a GitLab flaw matter for CAD and design data?

Engineering teams often keep firmware, PCB projects, CAD scripts and sometimes CAD files in GitLab, plus the credentials for PDM, PLM and cloud systems. Code execution on the server can expose all of it.

How does CADChain help if a repository server is breached?

CADChain encrypts CAD files and enforces per-file permissions, so a copy taken from a breached server cannot be opened without permission. It logs every access and records blockchain proof of ownership.
2026-10-24 13:25 News