GitLab shipped patches on September 10, 2026, for a maximum-severity vulnerability that let an unauthenticated attacker read arbitrary files off a self-managed GitLab server with a single API request. Tracked as CVE-2026-85706 and scored a full 10.0 on the CVSS scale, the flaw sits in the repository commits API and affects GitLab Community Edition and Enterprise Edition versions from 18.7 up to the patched releases: 19.1.8, 19.2.6, and 19.3.2. Attackers began probing for it within hours of disclosure, and CISA added it to its Known Exploited Vulnerabilities catalog the next day.
What CVE-2026-85706 Actually Lets an Attacker Do
According to GitLab’s own patch notes, the bug comes down to improper path confinement and missing authentication enforcement in the repository commits API. Any GitLab instance running an affected version with at least one public project is reachable: an attacker sends a crafted request to the commits endpoint with a manipulated file path parameter, and the server hands back the contents of files it should never expose, including server logs and GitLab’s own configuration files.
That matters because those log and config files routinely hold credentials, API tokens, and other secrets. An attacker who pulls the right file doesn’t need a second bug to turn read access into a real foothold. The leaked data can do that on its own.
Why This Moved from Disclosure to Active Attack in Hours
GitLab pushed 19.1.8, 19.2.6, and 19.3.2 on September 10 as part of a batch covering 17 vulnerabilities, alongside a near-maximum insecure deserialization flaw (CVE-2026-87719, CVSS 9.9) affecting Advanced Search on GitLab EE. GitLab.com was already running the fixed code before the announcement went out.
Researchers at watchTowr and reporting from The Hacker News both place the first exploitation attempts at around 06:00 UTC on September 11, less than a day after the patch shipped. CISA confirmed active exploitation and added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog that same day, giving federal civilian agencies until September 14 to patch. The gap between a patch going out and attackers scanning for it was measured in hours, not weeks, which is what turned a routine update into an emergency one for anyone running GitLab outside GitLab.com.
This is the second unauthenticated, maximum-or-near-maximum severity flaw GitLab has patched in under a month. A critical GraphQL vulnerability (CVE-2026-19478, CVSS 9.4) went out in mid-August. Neither bug required an attacker to have an account first.
What to Do If You Run Self-Managed GitLab
- Update to 19.3.2, 19.2.6, or 19.1.8 (or later) immediately if you haven’t already.
- If patching has to wait, restrict outside access to the instance, or confirm it has no public projects, since the exploit path requires one.
- Check access logs for repeated or unusual hits on the repository commits API endpoint around and after September 11.
- Rotate any credentials stored in server logs or GitLab configuration files, since those are exactly what this flaw exposes.
GitLab.com and GitLab Dedicated customers were never exposed, so this is a self-managed-instance problem specifically. That still covers a lot of ground given GitLab’s tens of thousands of self-hosted deployments, many sitting on the same infrastructure that handles other internet-facing services for the same team.
