GitLab fixed a second unauthenticated CVSS 10.0 flaw in its self-managed software within about a month, and I think the right response to that pace is to move the server behind a VPN or an identity-aware proxy.
Two maximum-severity scores in about a month
On October 12 GitLab released versions 19.4.2, 19.3.5 and 19.2.8 for Community Edition and Enterprise Edition. The notice describes CVE-2026-97229 as an integer overflow in the CI/CD regular expression compiler that, under certain conditions, could have let an unauthenticated user execute arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. It carries a CVSS score of 10.0, with a network attack vector, low complexity and no privileges or user interaction required.
The earlier one is on the CVE record. CVE-2026-85706, published on September 12, covers an unauthenticated user reading arbitrary files from the GitLab server through the repository commits API. It also scores 10.0. GitLab remediated both and credited the researchers who reported them through its bug bounty program. I have no complaint about that handling. The notice says GitLab.com already runs the patched version and that GitLab Dedicated customers need no action. That leaves the self-managed installations, and for those the notice says: “we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.”
Patch speed is not enough on its own
Patching is the advice every advisory gives, and operators should follow it. My argument is about what protects a server in the hours before an upgrade window opens. A self-managed GitLab instance holds source code, issue history, CI/CD variables and deploy credentials, and it often reaches into production through runners. When a flaw needs no login and the instance answers on a public address, the only control between the Internet and that stockpile is how fast an administrator reads an advisory and schedules an outage. Our earlier opinion piece argued that the patch clock should start on release day. Even a clock that starts early leaves a gap, and a network position that denies the request closes it.
So my recommendation is plain. Put the web interface and the API behind a VPN, an identity-aware proxy or a source-address allowlist, and let only the paths that must be public through a reverse proxy. A server that unauthenticated strangers cannot reach is unaffected by an unauthenticated flaw until someone gets inside the perimeter, which gives the team time to patch on a normal schedule.
The strongest objection
The best counter-argument comes from teams that run GitLab for outside contributors, customers or partners. They cannot put a VPN in front of a project that strangers need to clone, and webhooks from SaaS tools have to reach the instance. That is a fair constraint, and I expect it to describe a minority of installations. Most self-managed instances serve employees and contractors whose identities the company already controls, so a login in front of the whole site costs those users almost nothing. For the public-facing minority, the same logic shrinks the exposed surface: expose a mirror or a read-only front end, keep the administrative and CI/CD paths private, and keep runners on a segment that cannot be reached from outside.
A second objection says the flaw class matters, and that a file read or a regular expression bug is rare. Two maximum scores in about a month from one product suggest otherwise, and the edge-appliance flaws we have covered point the same way. Our coverage of the Citrix NetScaler SAML flaw and the case for an exposure inventory reach the same conclusion from the edge-appliance side.
What I would do on Monday
Check the version of every self-managed GitLab instance against the fixed releases named above, and upgrade any that sit on an affected line. Then list which GitLab hostnames answer from the public Internet and why each one does. For every instance with no stated reason, move it behind the VPN or proxy this week. Rotate the CI/CD variables and deploy tokens on any instance that was reachable and unpatched, because GitLab’s notice cannot tell you whether anyone used the window. Give the CI server the same network treatment as a production database, and write down who approves an exception so the next advisory starts from a known baseline.
Source: GitLab critical patch release 19.4.2, 19.3.5, 19.2.8
