CRITICAL: GitLab CVE-2026-85706 Unauthenticated File Read Hits CVSS 10

There is a specific rhythm to how these weeks go. A vendor ships a patch on a Thursday, publishes an advisory with the emotional range of a tax form, and by six the next morning honeypots on three continents are catching strangers throwing the exploit at anything that answers on port 443. GitLab just lived through that rhythm, and if you run a self-hosted instance, so did you, whether you noticed or not.

On September 10, GitLab released patch versions 19.1.8, 19.2.6, and 19.3.2 for both Community Edition and Enterprise Edition. The headline item was CVE-2026-85706, a path traversal flaw in the repository commits API that GitLab scored at CVSS 10.0. Not 9.8, which is the usual ceiling for bugs that require a little squinting. A flat ten. That score means unauthenticated, network reachable, low complexity, no user interaction, and a scope change that reaches past the application into the host underneath it. GitLab does not hand those out to be dramatic.

What actually broke

The bug lives in the API endpoint at /api/v4/projects/{id}/repository/commits/, which exists so that automation can create commits over HTTP without cloning a repository first. A commit action carries a file path, and that path is where everything fell apart. GitLab describes the root cause as improper path confinement combined with missing authentication enforcement on the affected endpoint, which is a polite way of saying two independent safety nets had holes in the same spot. The path parameter was never properly anchored to the repository working directory, so traversal sequences walked straight out of it, and the endpoint did not insist on a valid credential before honoring the request.

The practical result is that a single HTTP POST, with no token, no session, and no account of any kind, can ask a GitLab server to read a file and hand the contents back. There is one precondition worth knowing, and it is not much of a hurdle. The instance needs at least one public project. That is the default state of an enormous number of self-hosted GitLab deployments, because public projects are how internal documentation, shared runner configuration, and open source mirrors usually live. If your instance has a single public repository and it answers from the internet, assume you were reachable.

Jake Knott at watchTowr, whose team reported the issue, put the bar plainly when he noted that exploitation requires just one thing, that at least one public project must exist. That is the entire admission ticket.

What an attacker walks away with

Arbitrary file read sounds academic until you sit down and think about what actually lives on a GitLab box. The obvious first stop is /etc/gitlab/gitlab.rb and the secrets file that sits beside it, which together hold database credentials, the Rails secret key base, and the encryption keys that protect stored CI/CD variables. Those CI/CD variables are frequently the crown jewels of the entire estate, because that is where teams park cloud provider keys, container registry credentials, signing certificates, and deployment tokens for every system downstream of the pipeline. Reading application logs is nearly as productive, since production logs on a busy instance routinely capture tokens and request parameters that nobody ever intended to persist to disk.

Then there is the escalation path that turns a read primitive into something considerably worse. GitLab is a Rails application, and a Rails application that leaks its secret key base is a Rails application where an attacker can forge signed session cookies and, depending on the deployment, feed the framework serialized objects it will happily reconstitute. Anyone who has spent time on the offensive side of a Rails engagement knows exactly what that sequence looks like. File read is the opening move, not the whole game. Add source code for every private repository the instance hosts, and you have handed an intruder both the keys and the blueprints.

Already being probed

The disclosure happened on September 10. By 06:00 UTC on September 11, watchTowr was seeing behavioral probes for the vulnerability land on Attacker Eye, its global honeypot network, which means someone had already diffed the patch, reverse engineered the fix, and built a working request. That turnaround is measured in hours, not days. watchTowr assessed with high confidence that the bug would move rapidly toward indiscriminate mass exploitation given how little complexity is involved, and Knott framed the window bluntly, saying that based on the history, the transition to indiscriminate mass exploitation is likely not far away and defenders have limited time to act.

CISA agreed. The agency added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog on September 11 and set a remediation deadline of September 14 for federal civilian executive branch agencies. A three day KEV clock is not a routine entry. That is CISA telling everyone that the exploitation is real and the exposure is broad.

None of this should surprise anyone who has been watching GitLab advisories lately. This is the second maximum or near maximum severity GitLab flaw in recent weeks, arriving on the heels of CVE-2026-19478, a GraphQL code injection issue that also went from disclosure to active exploitation almost immediately. Self-hosted GitLab has become a favorite target for the simple reason that it sits at the center of the software supply chain, it is usually internet facing so remote developers and runners can reach it, and it is stuffed with credentials by design. Attackers have noticed the pattern even if some defenders have not.

Versions, and the other bug in the same release

The affected range is broad. GitLab CE and EE from 18.7 up to but not including 19.1.8 are vulnerable, as are the 19.2 series before 19.2.6 and the 19.3 series before 19.3.1. Practically speaking, if you are running anything from 18.7 onward and you have not patched since September 10, you are in scope. The fixed builds are 19.1.8, 19.2.6, and 19.3.2, and GitLab Dedicated and GitLab.com were handled by the vendor.

The same release also carried CVE-2026-87719, an insecure deserialization flaw in the GraphQL subscription serializer rated CVSS 9.9. That one affects Enterprise Edition and requires an authenticated user with access to Duo Chat, which narrows it considerably, but it exposes Advanced Search configuration and the credentials inside. Six additional high severity defects came along for the ride, covering remote code execution, unauthorized CI/CD variable access, cross-site scripting, and denial of service. The patch is worth applying on the strength of the ten alone, but there is plenty else in the box.

What to do about it

Patch. That is the short version, and there is no clever mitigation that beats it. Confirm the running version rather than the version you believe is running, because on GitLab those two numbers diverge more often than anyone would like, particularly on Omnibus installs where an upgrade stalled months ago and nobody followed up.

If you genuinely cannot patch inside the next day, take the instance off the public internet and put it behind a VPN or an identity aware proxy. A stopgap worth deploying alongside that is a WAF rule or reverse proxy block on POST requests to the commits API path that carry a file path parameter containing traversal sequences, though treat that as a speed bump and not a fix, because filter bypasses for traversal payloads are a solved problem for anyone competent.

Once patched, assume exposure and act accordingly. Any instance that was internet facing with a public project between September 10 and the moment you applied the fix should be treated as potentially read. Rotate the Rails secret key base, rotate database credentials, rotate every CI/CD variable and deploy token and runner registration token, and rotate any personal access tokens that show up in configuration or logs. Rotating secrets is tedious and everyone hates it, which is exactly why attackers count on it not happening.

For detection, hunt through your logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs containing a file path parameter, which is the signature watchTowr published. Traversal sequences in that parameter, or successful responses to that endpoint from unauthenticated sources, are the clearest indicators you will get. Pair that with a review of authentication logs and CI job history for anything that ran outside normal hours or pulled credentials it had no business touching. If an attacker got the secrets, the follow-on activity will show up in your cloud provider and registry logs long before it shows up in GitLab.

The MSP angle

Every client running a self-hosted GitLab, Jenkins, or Artifactory instance is sitting on a credential vault that nobody treats like one, and this CVE is the concrete example that turns a vague "you should be scanning your DevOps stack" conversation into a signed statement of work for continuous external attack surface monitoring and emergency patch management. Bundle the secret rotation work into a one-time CI/CD credential hygiene engagement, because the clients who most need it are precisely the ones who have never rotated a deploy token in their lives and will not do it on their own.