One request, every file: GitLab’s CVSS 10 flaw and the 24-hour clock you’re now on

One unauthenticated HTTP request. Every file on the server. That is the short version of CVE-2026-85706, a path-traversal flaw in GitLab’s repository commits API that GitLab rated a perfect CVSS 10.0. GitLab shipped the fix on 10 September 2026; by the next morning, security firm watchTowr was already watching probes for it in the wild. If you self-host GitLab, this is not a “schedule it for the sprint” item — it is a same-day patch, and the reason why is worth understanding.

What the flaw actually does

The bug lives in the repository commits API. Because of improper path confinement and missing authentication enforcement, an outsider can craft a request to the commits endpoint and walk straight out of the repository directory into the rest of the filesystem. No login, no token, no project membership. Whatever the GitLab process can read, the attacker can read.

On most servers arbitrary file read sounds like a medium-severity nuisance. On GitLab it is close to game over, and that is exactly why the score is a 10. A GitLab box is a treasure chest of secrets in predictable locations: the gitlab.rb configuration, the Rails secret_key_base, database credentials, CI/CD variables, private SSH and deploy keys, and access tokens sitting in logs. Read the secret key base and an attacker can forge session cookies and authentication tokens — turning “I can read a file” into “I am an administrator.” From there the credentials inside lead outward to every system your pipelines touch.

Why the whole release matters, not just the 10

The CVSS 10 grabs the headlines, but GitLab patched three serious issues in the same release, and together they read like a full compromise chain. CVE-2026-87719 (CVSS 9.9) is an insecure-deserialization flaw reachable through GraphQL that exposes credentials. CVE-2026-88765 (CVSS 8.5) is a buffer overflow triggered during Git project imports that can lead to code execution. An attacker who reads your secrets with the first bug, harvests more with the second, and lands code with the third does not need three separate breaks — they need one unpatched instance.

This is a supply-chain problem, not just a server problem

A GitLab instance is rarely just one more web app. It holds your source code, your build pipelines, and the keys those pipelines use to push to production, cloud accounts and package registries. When someone reads secrets off that box, the blast radius is not the GitLab server — it is everything your CI/CD can reach. That is why more than 30 million developers and 100,000 organisations running GitLab makes this a genuine supply-chain event, and why a quiet file-read bug earns the same urgency as a loud remote-code-execution one.

Your next 24 hours

There is no clever workaround here — GitLab is explicit that patching is the fix. If you self-host, work down this list today, in order:

• Patch now. Upgrade to 19.1.8, 19.2.6 or 19.3.2 (versions from 18.7 up to those are affected). This is the whole fix; everything below assumes it is done.
• Assume you were probed. Scanning started on 11 September. If your instance faced the internet, check access logs for unusual requests to the commits endpoint and treat a hit as a possible read of your secrets. Managed detection and response and SIEM log monitoring turn those logs into an actual answer.
• Rotate every secret the server held. If there is any doubt, rotate the secret_key_base, CI/CD variables, deploy keys, tokens and database credentials — a stolen secret_key_base lets an attacker forge sessions long after you patch.
• Get GitLab off the open internet. A code platform almost never needs to be reachable by the whole world. An external network penetration test shows exactly what of yours is exposed, and API security monitoring watches the endpoints that flaws like this abuse.
• Watch for fallout. If secrets did leak, they surface in credential dumps before they are used. Dark-web monitoring gives you early warning that yours are in circulation.

The bigger lesson

CVE-2026-85706 is a reminder that “just a file read” is a severity trap. Context decides impact: the same primitive is a shrug on a static brochure site and a full takeover on a secrets-dense platform like GitLab. The teams that came through the SharePoint, PaperCut and Citrix mass-exploitation waves unscathed were not the ones with the best tools — they were the ones who patched internet-facing infrastructure in hours, not weeks. The window between a CVSS 10 disclosure and automated exploitation is now measured in hours, and the only reliable defence is treating critical patches on exposed systems as an emergency.

If you are not sure what you have exposed or whether an old GitLab is quietly listening on the internet, that uncertainty is the real risk. A focused external penetration test and continuous vulnerability management answer the question before an attacker does — talk to our team and get ahead of the next CVSS 10 instead of reacting to it.