A CVSS-10 Path Traversal in GitLab's Commits API Is Being Exploited

TL;DR

• GitLab patched CVE-2026-85706, a path traversal in the repository commits API letting an unauthenticated attacker read arbitrary files from the server — CVSS 10.0, disclosed with the 19.3.2 / 19.2.6 / 19.1.8 critical patch release.
• CISA added it to the Known Exploited Vulnerabilities catalog on September 11, 2026 — active exploitation, not a theoretical risk. The KEV entry is what should set the priority.
• The affected range is broad: GitLab CE/EE from 18.7 before 19.1.8, 19.2 before 19.2.6, 19.3 before 19.3.2.
• GitLab.com and GitLab Dedicated are already patched; the exposure is on self-managed instances, which must patch themselves.
• What to do now: patch before anything else, verify the running version, then replay the three GitLab detection signatures against your historical logs.

A file-read primitive inside the tool that holds your source

On September 11, GitLab shipped a critical patch release that closed CVE-2026-85706: a path traversal in the repository commits API that let an unauthenticated user read arbitrary files from the server. Read the advisory's own wording carefully, because the two faults it names are the story. GitLab describes "improper path confinement and missing authentication enforcement in the repository commits API" — that is an endpoint that forgot to do two of the three basic things an endpoint should do (check the path stays inside the intended root, check who is calling). Not an exotic side-channel; a routine omission with maximum severity.

The severity number matters. CVSS 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N is about as close as the scoring system gets to "no conditions": network-reachable, no privileges, no user interaction, and the confidentiality impact is high with a scope change. For a self-managed GitLab, "arbitrary files" includes gitlab.yml and its secrets, repository contents, OAuth tokens, and anything else mounted where the Rails process can read it. In a tool whose entire job is to be the single source of truth for code, an unauthenticated file read is close to the worst possible primitive.

CISA's KEV entry is the part that should set the priority

The CISA Known Exploited Vulnerabilities catalog entry is the operational signal. CISA adds vulnerabilities to KEV only based on evidence of active exploitation — and under BOD 26-04 the entry imposes rapid-remediation deadlines on US federal agencies. For everyone else it is still the clearest public indicator we have that attackers are already using the flaw. When a CVSS 10.0 file read in a self-managed DevSecOps tool is both patchable and exploited, the ordering question is over. Feature upgrades wait; this one does not.

The affected range is wider than your upgrade plan probably is

GitLab's advisory lists impacted versions as GitLab CE/EE from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. Three release lines, each needing its own patch. The practical failure mode at most self-managed sites is different: the instance sits on an earlier major (18.x, 17.x), possibly already past its support window, in a container or VM that has not moved in months because "nothing broke." That instance is still listed — the advisory's impact statement starts at 18.7, but the repository commits API exists on every GitLab. The responsible reading of the advisory is: if your instance is 18.7 or newer and not on one of the three patched points, you are affected; if it is older, you are patching everything, because the endpoint has been there longer.

Managed versus self-managed is now a security statement

GitLab's own notes say the managed infrastructure — GitLab.com and GitLab Dedicated — remains patched. That sentence is doing more work than it looks like. For a company that picked self-managed GitLab partly to control its own data, the trade came due: you kept control of the instance, and you inherited the patch duty. There is no shame in self-managed as a choice; there is only the requirement that the choice include an update process that can move an instance within days of a KEV entry. A workload identity routine and patch cadence are the same discipline: the boundary only protects you if you operate it.

What to do now

Start with the patch. Upgrade to 19.3.2, 19.2.6, or 19.1.8 (or later) depending on your line, then verify the running version. After that, do the retrospective: GitLab released three threat detections for self-managed instances — an LFI attempt reading gitlab.yml, an LFI via the metadata.path parameter, and LFI file-path enumeration. Apply them, then replay them against historical access logs. The hard part is not the patch; it is the assumption that you would have noticed exploitation from routine log glance. Most teams would not: the requests look like ordinary commits-API calls.

For a review of your CI/CD security posture — patch cadence, workload identities, and the access boundaries around your code platforms — start from the Netics homepage. The patch is the immediate fix; the process is what survives the next CVE.

Sources

• GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 — GitLab Docs, September 2026.
• CISA Adds One Known Exploited Vulnerability to Catalog — CISA, September 11, 2026.

Source: "GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8" — docs.gitlab.com, September 11, 2026.