GitLab CVE-2026-85706: A Perfect 10 That Lets Attackers Read Files Without Logging In
GitLab patched CVE-2026-85706 on September 10: a path traversal flaw with a CVSS score of 10.0 that lets an unauthenticated caller read files from the server. Within 24 hours probes showed up online and CISA added it to its known-exploited catalog.
Most breaches start with a forgotten dependency or a badly stored token. This time the hole was in the tool that stores the code.
What CVE-2026-85706 Is
CVE-2026-85706 is a path traversal vulnerability in GitLab's repository commits API. It combines two mistakes: incorrect path confinement and a missing authentication check. Under certain conditions, someone with no account and no token can ask the server for a file and GitLab hands it over.
Path Traversal in the Repository Commits API
Path traversal is a classic: the attacker builds a path that climbs up through the file system and the program never validates the final destination. Here the vector is the commits API, and the detail that makes detection harder is that the path travels in the request body rather than in the URL.
Read also
No Login, No Password: Why It Scores a Perfect 10
The CVSS scale punishes a specific combination: remote exploitation, no authentication, no user interaction and a total loss of confidentiality. CVE-2026-85706 checks all four boxes, which is why it earns the maximum score. No advanced technique is required to abuse it: reaching the service is enough.
What Can Be Read: Config, Logs, Tokens and Keys
That machine holds the configuration file, application and reverse proxy logs, database connection details and, very often, SSH keys and integration tokens for other services. Those credentials open doors elsewhere without touching the original flaw again.
Which Versions Are Affected
The advisory targets self-managed instances, both Community Edition and Enterprise Edition. If you use GitLab.com or GitLab Dedicated you have nothing to do: the fix was applied on the server side.
GitLab CE and EE: From the 18.7 Branch to 19.3.1
Versions before 19.1.8 in the 19.1 branch, before 19.2.6 in the 19.2 branch and before 19.3.2 in the 19.3 branch are considered vulnerable. Older branches, from 18.7 backwards, also fall inside the affected range and no longer receive maintenance, so the recommendation there is to move to a supported release.
The Patched Versions: 19.3.2, 19.2.6 and 19.1.8
GitLab shipped the fixed releases on September 10, 2026 for both editions, as part of a patch bundle with more than a dozen security and bug fixes. The upgrade installs through the usual channels, either the system package or the container image.
GitLab.com and GitLab Dedicated Are Already Covered
The company confirmed that its cloud services were patched at disclosure time. The real exposure sits in the installations each team runs on its own VPS or office server.
Exploitation Followed Within 24 Hours
From the September 10 Patch to the September 11 Probes
Security firm watchTowr reported scanning activity on September 11, one day after disclosure, and warned that mass exploitation was likely given how simple the vector is. The window between "a patch exists" and "scanners are out" is now measured in hours, not weeks.
CISA Adds It to the KEV Catalog with a September 14 Deadline
The US cybersecurity agency added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on September 11, with a remediation deadline of September 14 for civilian federal agencies. Landing on that list means exploitation in practice, not on paper.
The Second Flaw in the Same Patch: CVE-2026-87719
The release also carried CVE-2026-87719, an insecure deserialization bug in the GraphQL subscriptions serializer, rated 9.9 and limited to Enterprise Edition. Do not mix the two up: the first is an unauthenticated file read affecting CE and EE.
What to Do If You Run a Self-Managed Instance
Upgrade First, Ask Questions Later
The recommended mitigation is to upgrade to 19.3.2, 19.2.6 or 19.1.8 depending on your branch. A VPN or an IP allow-list shrinks the attack surface while you prepare a maintenance window, but it does not replace the patch.
Check the Logs: Commits API Requests with Path Traversal Sequences
Because the path travels in the request body, the URL alone in your log will not reveal the attempt: look for unauthenticated requests to the commits API and inspect their parameters. The community has already published forensic guides and indicator-of-compromise scanners for this CVE.
Rotate Secrets and Keys If the Instance Was Exposed
If your server was reachable from the internet and unpatched during those days, assume the configuration files could be read: rotate access tokens, SSH keys and database credentials. It is work, and it is far cheaper than an intrusion.
Conclusion
The lesson matches the RubyGems attack we already covered on the blog: developer tools are a priority target because they concentrate credentials and access to everything else. Patching GitLab today takes minutes; investigating an incident afterwards takes weeks.
To keep going, the blog has the AI agent attack on RubyGems, security in open source and best security practices in Laravel.
