Unauthenticated Arbitrary File Read in GitLab CE/EE Repository APIs
CVE-2026-85706 is a critical path traversal and missing-authentication vulnerability affecting self-managed GitLab Community Edition and Enterprise Edition. Differences in URL interpretation between GitLab Workhorse and Rails allow crafted requests to bypass expected upload handling while reaching repository API handlers. A body-upload helper processes attacker-controlled file metadata before authentication and without adequate path confinement, allowing reads of local files accessible to the GitLab service process. The repository Commits API is affected, with equivalent behavior also demonstrated in the Repository Files API. File contents can be disclosed through error responses under suitable parsing conditions; other requests can provide an existence or readability oracle. Affected releases are versions from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The vulnerability has a reported CVSS score of 10.0, is actively exploited, and is listed in CISA's Known Exploited Vulnerabilities catalog.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Exploitation compromises the confidentiality of files readable by the GitLab service account, generally the git user. Potentially exposed information includes application configuration, logs, database credentials, deployment and runner tokens, cryptographic secrets, SSH private keys, and source code. Stolen credentials and secrets may enable unauthorized authenticated access, session or token forgery where applicable, compromise of CI/CD pipelines, and lateral movement into connected infrastructure or downstream software supply chains. The vulnerability directly provides file reads, not file writes or remote code execution; further compromise depends on the information disclosed and deployment configuration.
If you can’t patch tonight, do this now.
If immediate patching is impossible, remove public exposure or restrict access to trusted networks through a VPN, firewall, or IP allowlist. As an interim compensating control, restrict POST and PUT traffic to repository Commits and Repository Files APIs at a reverse proxy or WAF, accounting for encoded and alternate route forms. Remove anonymous repository access where operationally feasible and disable unnecessary open registration as defense in depth. Normal login gating alone may leave public projects reachable. Monitor suspicious unauthenticated API requests and unexpected file-access behavior. These controls reduce exposure but do not replace upgrading.
Patch, then assume compromise.
Immediately upgrade affected self-managed GitLab CE/EE installations to an applicable fixed release: 18.11.12, 19.0.9, 19.1.8, 19.2.6, or 19.3.2, or a later supported release. Prefer a currently supported release over the exceptional 18.11 and 19.0 backports, which contain only selected security fixes. Follow GitLab's architecture-specific upgrade procedures and verify the installed version afterward. Investigate historical repository API traffic and application logs for exploitation, using GitLab's published file-read detections where available. Rotate potentially exposed credentials, tokens, and cryptographic secrets and invalidate affected sessions; patching does not invalidate information already stolen. Assess connected systems and build artifacts if compromised credentials could have been used. GitLab.com and GitLab Dedicated were already patched.
16 exploits validated by Mallory's analysis. Hidden: 2 rejected by Mallory's analysis as not a working exploit; 1 not yet analyzed, such as Exploit-DB entries.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
397 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.