12 SEP 2026 — GitLab patched a path traversal in its repository commits API on 10 September, rated CVSS 10.0, that lets an unauthenticated attacker read arbitrary files from a self-managed server. Probes for it were seen against honeypots within a day of the fix shipping.
That interval is the story. For self-hosted software, a patch does not end the exposure. It publishes the map.
What the flaw allows
CVE-2026-85706 combines improper path confinement with missing authentication enforcement in the repository commits API. Under certain conditions an attacker who has not logged in at all can read files outside the intended repository path.
The 10.0 is not inflated. Unauthenticated and arbitrary file read on a service that organisations deliberately expose is the combination CVSS is designed to score at the top. GitLab assigned the score itself; no researcher had to argue it upward.
What sits on a GitLab server is what makes it worse than the score suggests. Deployment credentials, CI/CD secrets, cloud tokens, signing keys, database connection strings and the source of everything the organisation builds are all files. An arbitrary file read against a build system is not one breach; it is a compromise of the credentials for every system that build server can reach.
The versions, precisely
The fixed releases are 19.3.2, 19.2.6 and 19.1.8, for both Community and Enterprise editions. Affected are 18.7 up to but not including 19.1.8, 19.2 up to but not including 19.2.6, and 19.3 up to but not including 19.3.2.
Read the first range carefully, because it is wide. Anything from 18.7 forward that has not reached 19.1.8 is in scope, which covers instances several minor versions behind that their owners may reasonably have considered maintained.
This affects self-managed installations. Users of GitLab.com are not the population at risk; the exposure is in self-hosted instances, which many organisations run precisely to keep source code in-house.
Patch diffing is not a theory
Behavioural probes against honeypot networks a day after release mean somebody took the patch, compared it with the previous build, worked out what had been fixed, and built a test for it. That is routine work for a competent researcher, and both watchTowr and Horizon3 published rapid analyses in the same window.
The uncomfortable implication for defenders is structural, not specific to GitLab. In an open-source product, the commit that fixes a flaw also describes the flaw. Publishing it is still correct; silent patching would leave defenders unable to prioritise while attackers reverse it anyway. But it does turn the release into a starting gun.
The practical consequence is that self-hosted infrastructure now has a patch window measured in hours. An organisation whose upgrade process requires a change advisory board meeting no longer has a patching process for this class of flaw; it has a scheduling process.
How you would know
An arbitrary file read is among the quietest primitives there is, but it is not silent. It arrives as an HTTP request, and those appear in server logs.
Look for traffic to the repository commits API that carries path components that do not belong in a repository path — traversal sequences, absolute paths, encoded variants of either — from clients that never authenticated. Most instances will have none, and the search is cheap enough to run even on a patched server. You are checking whether anything happened before the upgrade, not whether anything can happen now.
One qualifier in the advisory matters while you run that search. GitLab says the read is possible "under certain conditions" and does not enumerate them. That phrasing is standard practice, but it means an operator cannot tell from the advisory whether their configuration was exposed. Without that detail, the safe reading of a 10.0 is that the conditions were met, not that they were exotic.
What to do, in order
Upgrade to the fixed build for your line rather than jumping major versions, which is what the three separate backports exist for.
Then assume the window between disclosure and your upgrade was exploitable and act accordingly. Rotate CI/CD variables, deploy keys, personal access tokens and any cloud credential the runner could assume. Unlike a failed login, an arbitrary file read leaves no distinct trace in application logs, so a clean login history proves very little.
If the instance was reachable from the public internet, treat that as the finding rather than the flaw. Very few self-managed GitLab servers need to answer to the whole world. The ones that do are a standing bet that no unauthenticated flaw will ever be found in a large Ruby application.
The second maximum-severity GitLab flaw we have covered
In August we wrote about a GitLab flaw that let anyone delete public projects. That one destroyed; this one reads. The two are a study in contrasts: deletion is obvious immediately, while an arbitrary file read may never be detected at all.
It is also the fourth time this year we have written up a maximum-severity flaw in software that sits between developers and production. We have seen this pattern all quarter in software at the internet-facing edge. Build infrastructure is a recurring target because it is both externally reachable and internally trusted.
What to watch
Whether this reaches CISA's exploited catalogue, which would move it from probing to confirmed use and put a federal deadline on it. Probing is not exploitation, and the distinction is worth holding until somebody demonstrates the second.
And whether any incident is attributed to it. Because arbitrary file read is a quiet primitive, the compromises it enables tend to surface weeks later, when the stolen credentials are used against a system with no obvious link to a GitLab server.
View author profile → · Editorial policy
