GitLab told self-managed customers on September 10 to patch immediately against a vulnerability it rated 10.0 out of 10 on the CVSS scale, the highest severity score the system allows. The flaw, tracked as CVE-2026-85706, let an unauthenticated remote attacker read arbitrary files from a GitLab server because the repository commits API failed to confine file paths and did not enforce authentication under certain conditions, according to GitLab's own advisory as reproduced by vulnerability trackers Tenable and Rapid7.

The bug affects GitLab CE and EE across three release lines: versions from 18.7 up to 19.1.8, from 19.2 up to 19.2.6, and from 19.3 up to 19.3.2. GitLab shipped fixed builds — 19.1.8, 19.2.6 and 19.3.2 — alongside the advisory. Within days, CISA confirmed active exploitation and added the CVE to its Known Exploited Vulnerabilities catalog on September 11, 2026.

Why it matters

GitLab instances are frequently the most sensitive box on a corporate network: they hold source code, CI/CD secrets, deployment keys and often direct pipelines into production. A file-read vulnerability that requires no login turns any internet-facing GitLab server into a low-effort target for reconnaissance and credential theft, and it can be chained with other bugs to escalate further.

GitLab's self-managed customer base spans everything from small engineering teams to large enterprises and government contractors running on-premises instances, many of which lag behind SaaS in patch cadence. That gap is exactly what CISA's KEV listing is meant to close by forcing federal civilian agencies onto a firm remediation deadline.

How it works

According to the technical description carried by Tenable and OpenCVE, the repository commits API did not properly confine requested file paths to the intended repository directory and, under certain conditions, did not require authentication at all. That combination let an attacker craft a request that traversed outside the expected file scope and returned the contents of files elsewhere on the server's filesystem — a classic path traversal pattern, but unusually severe here because no valid account was required.

Neither GitLab nor CISA has published exploitation details, and this report does not include proof-of-concept steps. Security teams should treat any request logs showing anomalous paths against the commits API, or unexpected reads of files outside repository directories, as a possible indicator of compromise.

Evidence

The vulnerability is documented directly in GitLab's advisory and mirrored by BleepingComputer, which reported that GitLab "urged users on Thursday to patch their servers immediately". Rapid7's vulnerability database and Tenable both list the affected version ranges and the fixed releases identically. CISA's catalog entry from September 11, 2026 confirms evidence of active exploitation in the wild and sets a remediation deadline for federal agencies.

What defenders should do

Any organization running self-managed GitLab CE or EE in the affected version ranges should upgrade to 19.1.8, 19.2.6, 19.3.2 or later immediately, and should not treat this as a routine patch cycle given the KEV listing and the missing-authentication component. Administrators should also review access logs for the repository commits API for unusual file-path patterns predating the patch, and rotate any secrets or tokens that might have been stored in accessible files, since a file-read bug of this severity can expose CI/CD credentials even without a follow-on exploit.

What happens next

GitLab's SaaS offering was already remediated, so exposure is concentrated in self-managed deployments that have not yet updated. Expect security vendors to publish more detailed exploitation writeups in the coming weeks as incident responders find the flaw in the wild, and expect CISA's binding operational directive timelines to force faster patching inside federal networks than is typical for enterprise software.