# GitLab's CVSS 10 Path Traversal Flaw Is Already Being Probed — Patch Now
## The Threat
A maximum-severity vulnerability in GitLab's repository commits API is drawing active exploitation attempts in the wild, with probes emerging within hours of the patch dropping. CVE-2026-85706 is a path traversal flaw that lets an unauthenticated attacker read arbitrary files directly off the GitLab server — no credentials, no session, no social engineering required. You simply send a crafted request to the commits API and the server hands you files it was never supposed to expose.
Path traversal at this level is about as bad as it gets for a self-hosted DevOps platform. GitLab instances routinely hold source code, CI/CD pipeline secrets, deploy keys, API tokens embedded in configuration files, and private repository data. An attacker who can freely walk the filesystem doesn't need to escalate — they've already won. They can extract credentials that unlock cloud infrastructure, signing keys that compromise software supply chains, or proprietary code that represents a company's competitive advantage.
The speed of exploitation matters here. When researchers observe in-the-wild probes within hours of disclosure, it signals that exploit code was either pre-built from a leaked patch diff, or the vulnerability is simple enough that independent researchers and threat actors converged on it simultaneously. Either way, the window between "patch available" and "actively exploited in production" has collapsed to near-zero for this one.
## Severity and Impact
| Field | Detail |
|---|---|
| CVE | CVE-2026-85706 |
| CVSS Score | 10.0 (Critical) |
| Vector String | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| CWE | CWE-22 — Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) |
A CVSS 10.0 requires hitting the ceiling on every dimension: remotely exploitable, trivially simple, no authentication, no victim interaction, and cascading impact across confidentiality, integrity, and availability. This one checks every box.
## Affected Products
> Organizations running self-managed GitLab deployments are the primary exposure. GitLab.com users should verify their instance's patch status via the GitLab security release page. All CE and EE installations that have not been updated to the latest patched version should be treated as compromised until proven otherwise.
## Mitigations
Primary remediation — upgrade immediately:
Update to the patched GitLab release as soon as operationally feasible. GitLab's security advisories provide version-specific patch guidance; consult the official release page for your major version branch.
If immediate patching is not possible:
/api/v4/projects/*/repository/commits that contain path traversal sequences (../, %2e%2e, URL-encoded variants)..env files accessible to the server process.Monitor GitLab's official security tracker for additional indicators of compromise and updated patch guidance as the situation develops.
## References
---
## HackWire Analysis
There's a pattern here that deserves more attention than the patch bulletin typically gets: DevOps platform vulnerabilities at maximum severity are disproportionately dangerous compared to equivalent flaws in application software, and the security community still underweights that.
When a CVSS 10 lands in a CRM or a web app, the blast radius is the data that application touches. When a CVSS 10 lands in GitLab, the blast radius is *everything that application was ever used to build or deploy*. Source repositories are treasure maps. CI/CD pipelines are loaded with cloud credentials, container registry tokens, code signing certificates, and deployment keys. A single unauthenticated file read on the wrong server is a supply chain compromise waiting to happen — attackers don't need to implant malicious code themselves if they can steal the keys that let them push to a trusted repository undetected.
The hours-to-probe timeline here mirrors what we saw with CVE-2023-7028 (GitLab account takeover) and CVE-2021-22005 (VMware vCenter file upload). In both cases, threat actors — including nation-state groups — moved fast because DevOps and infrastructure management tools give outsized return on exploitation investment. GitLab specifically has become a target of sustained interest from advanced persistent threat actors looking to pre-position inside software supply chains.
For defenders, the practical takeaway is blunt: self-managed GitLab instances that are internet-facing without WAF controls or strong IP restrictions are facing active targeting right now, today, not in a theoretical future scenario. The asset class — DevOps platforms — warrants dedicated hardening that goes beyond keeping the application updated. Patch, rotate secrets, and audit logs going back at least 72 hours from the time of disclosure.
— *HackWire Editorial*
---
## Related Coverage