CVE-2026-85706 carries a CVSS score of 10.0, the maximum the scale allows, and the reason is almost insultingly simple. GitLab's repository commits API takes a file.Path parameter and, on affected versions, doesn't confine it properly before using it to read a file off disk. Send the right crafted POST request to /api/v4/projects/{id}/repository/commits/ and the server hands back the contents of whatever path you asked for - log files, GitLab's own configuration, credentials, anything the process can see. No login required. According to The Hacker News's write-up, watchTowr's head of threat intelligence Jake Knott put the barrier to entry about as low as it goes: "Exploitation requires just one requirement, at least one public project must exist." On a self-managed GitLab instance used for anything resembling normal open collaboration, that requirement is already met before an attacker does anything at all.
Patched quietly, disclosed loudly, probed within hours
GitLab released 19.1.8, 19.2.6 and 19.3.2 on 10 September, fixing every affected branch back to 18.7. What happened next is the part worth paying attention to. The technical detail didn't reach the public until the following day, 11 September - and per watchTowr's own telemetry, cited in the same report, the first in-the-wild probes for the flaw started at 06:00 UTC that same day, within hours of the write-up landing. That's not a gap measured in weeks or even days anymore. A patch quietly shipped a day earlier bought self-managed customers almost no head start once the details of what it fixed became public.
CISA's clock runs out tomorrow
CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on 11 September, the same day the probing started, giving federal agencies until 14 September to remediate - BleepingComputer's coverage and CISA's own advisory summary both confirm the KEV addition landed the same day as the public disclosure, which is about as fast as that process moves. If your organisation runs a self-managed CE or EE instance in the 18.7 to 19.3.1 range and hasn't patched yet, that federal deadline is a reasonable proxy for how much runway you have left, whether or not a government mandate applies to you.
Why a file-read bug in your Git server is worse than it sounds
A path traversal that only reads files, rather than writing them or running code, tends to get filed mentally as "less bad" than a remote code execution bug. GitLab is a bad place to make that assumption. A self-managed instance's own configuration files routinely hold database credentials, SMTP secrets, and tokens for whatever CI/CD runners, container registries and external integrations the instance talks to. A GitLab server isn't just a place code sits - it's a place with standing, often broadly-scoped credentials to nearly everything else in a software delivery pipeline. Reading the wrong file off that box converts a "read-only" bug into a route to the rest of your infrastructure in one step.
- Upgrade self-managed GitLab CE/EE to 19.1.8, 19.2.6 or 19.3.2 (or later) immediately if you're anywhere in the 18.7 to 19.3.1 range.
- Treat the 14 September KEV deadline as your own internal deadline even if you're not a federal agency - probing started within hours of public disclosure, and this is not a bug that rewards a leisurely patch cycle.
- Assume any credentials or tokens stored in configuration files on an unpatched, internet-reachable instance may have been exposed, and rotate them once you've patched.
- Check your instance's exposure: an internet-facing GitLab install with even one public project meets the entire precondition for this exploit.
- Review GitLab access and audit logs for anomalous requests to the repository commits API predating your patch, particularly requests with unusual or traversal-pattern
file.Pathvalues.
A maximum-severity score and a same-day KEV addition are GitLab and CISA both telling you the same thing at once. If you need help auditing what a compromised GitLab instance could actually reach in your environment, email sales@halfteck.com.