GitLab's Perfect 10 Is Patched. The Secrets It Read Are Not

GitLab shipped a critical patch release on 10 September closing CVE-2026-85706, a path traversal flaw in the repository commits API scored CVSS 10.0. CISA added it to the Known Exploited Vulnerabilities catalogue the next day, citing evidence of active exploitation, and gave federal civilian agencies a three-day remediation deadline — the shortest window the agency issues. That deadline has now passed. The security firm watchTowr reported in-the-wild probing from 11 September.

The sequence matters more than any date in it. One day separated a vendor patch from a government catalogue entry that exists only for flaws attackers are already using. For anyone running GitLab on their own infrastructure, the gap between the fix being published and the fix being applied was the interval in which the server was readable by anyone who asked.

What the flaw is

GitLab's advisory describes it plainly:

GitLab has remediated an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.

The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N — reachable over the network, low attack complexity, no privileges, no user interaction, and, the component that pushes it to a perfect ten, scope changed. Scope changed is the scoring system's way of saying the blast radius does not stop at the vulnerable software. That is the correct call here, and the rest of this piece is an argument for why.

The issue was reported through GitLab's HackerOne programme by a researcher credited as s3ntago. GitLab.com and GitLab Dedicated already run patched code, so this is a self-managed problem exclusively.

The same release fixes a second critical issue — CVE-2026-87719, a GraphQL deserialization flaw in Enterprise Edition — plus six high-severity bugs. Anyone upgrading for the file read collects those too, which is an argument for upgrading rather than hunting for a mitigation that leaves the rest in place.

A file read on a source-control server is not a file read

Arbitrary file read is usually classed a notch below remote code execution, and in most contexts that is fair. A self-managed GitLab instance is not most contexts. It is the machine an organisation has deliberately made the custodian of the credentials that reach everything downstream: CI/CD variables, deploy tokens, runner registration tokens, container registry credentials, cloud provider keys, signing material, the configuration that stitches them together. The whole value proposition of an integrated DevSecOps platform is that those secrets live in one place so pipelines can reach them.

Read access to that host is therefore not read access to one server. It is read access to the keys for the estate the server deploys to. An attacker who never executes a line of code on the GitLab box can still authenticate as it to everything else, and everything they do afterwards looks like a pipeline doing its job. That is what scope changed means in practice, and it is why this belongs in the same mental category as a directory-service compromise rather than an information disclosure bug.

Patching closes the door. It does not recall the keys

This is the part organisations defer, and the reason to write about the story days after the patch landed.

Upgrading to 19.3.2, 19.2.6 or 19.1.8 stops the reading. It does nothing about what was already read. Any secret held on an exposed instance before the upgrade should be treated as disclosed and rotated — and rotation on a mature GitLab deployment is a long, tedious, cross-team job touching pipelines that will break loudly when a token changes. It is exactly the kind of work that gets scheduled for next quarter and then does not happen.

Rapid7 is direct about it, recommending organisations look for signs of compromise even after the update has been applied, and pointing to the forensic triage obligations attached to the KEV entry under CISA's BOD 26-04. Federal agencies are required to do that work. Everyone else is merely exposed to the same attackers.

Two operational notes worth knowing before scheduling the upgrade. The patch includes database migrations, so single-node installations will take downtime — plan it rather than discovering it. And the one-day gap between patch and KEV listing is the number to reason from when deciding whether rotation is warranted: if an instance was internet-facing and unpatched at any point after 10 September, assume it was reached.

The wider point

CISA describes path traversal as a frequent attack vector for malicious cyber actors, which is a bureaucratic way of noting that this class of bug has been well understood for roughly three decades and keeps appearing in the most sensitive software people run. The interesting question is not how a path confinement check was missed. It is why so many organisations have concentrated every credential they own behind a single internet-facing web application and have no rehearsed procedure for rotating them when that application fails.

The patch is available and the fix is straightforward. The bill that comes after the patch is the one that will not get paid, and it is the larger of the two.

Sources: GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 · Rapid7: CVE-2026-85706 Critical GitLab Path Traversal Exploited in the Wild · BleepingComputer: CISA — hackers now exploit max severity GitLab flaw in attacks · The Register: Perfect-10 GitLab bug under attack days after patch lands · Infosecurity Magazine: Hackers Exploit Maximum Severity Flaw in GitLab · CISA Known Exploited Vulnerabilities Catalog