Skip to content

Back to the catalog

Rapid Reaction: GitLab Critical Path Traversal Vulnerability (CVE-2026-85706)
watchtowr.comadvisory

Rapid Reaction: GitLab Critical Path Traversal Vulnerability (CVE-2026-85706)

watchTowr's rapid-reaction analysis of CVE-2026-85706, a critical (CVSS 10.0) unauthenticated path traversal in GitLab CE/EE's repository commits API, patched in versions 19.3.2, 19.2.6, and 19.1.8. The flaw lets an unauthenticated attacker read arbitrary files (configs, secrets) from self-managed GitLab servers via crafted requests to /api/v4/projects/{id}/repository/commits/ with a file.path parameter; watchTowr reproduced the bug and reports honeypot probes indicating attackers have already reverse-engineered it ahead of mass exploitation.

TL;DR Unauthenticated, CVSS 10.0 path traversal in GitLab's repository commits API (CVE-2026-85706) is already being probed in the wild — patch to 19.3.2/19.2.6/19.1.8 now.
Document

What it is

CVE-2026-85706 is a critical (CVSS 10.0) path traversal in the repository commits API of GitLab CE and EE. GitLab published fixes on September 10, 2026 in versions 19.3.2, 19.2.6, and 19.1.8. An unauthenticated attacker can read arbitrary files — configs, secrets, CI/CD data — from self-managed servers. watchTowr reproduced the bug and reports its Attacker Eye honeypot network is already seeing behavioral probes, meaning the flaw has been reverse-engineered and mass exploitation is imminent.

How it works

Root cause is improper path confinement combined with missing authentication enforcement on the affected endpoint. An unauthenticated request to the commits API returns file contents the application should never expose. The low complexity plus zero-auth path is what drives the 10.0 rating.

Preconditions / Affected

Self-managed / self-hosted GitLab CE and EE on versions prior to the patched releases, especially public-facing instances. GitLab.com and GitLab Dedicated require no action — worth documenting for audit purposes rather than re-verifying under pressure.

What to do

  • Inventory every self-managed GitLab instance and confirm the exact version; upgrade affected ones to 19.3.2, 19.2.6, or 19.1.8.
  • If you cannot patch immediately, remove public access to the instance.
  • Hunt logs for exploitation attempts — the page's concrete detection guidance:

Hunt through log files for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs containing a file.path parameter.

The POST method and the file.path parameter are the specific indicators; treat unauthenticated hits on this endpoint as probing or exploitation.

Caveats

This is a rapid-reaction post keyed to disclosure, not a full write-up: watchTowr confirms reproduction and honeypot probes but does not publish a proof-of-concept, the exact traversal payload, or the "certain conditions" GitLab says are required. The affected-versions table and product list rendered empty in the fetched text — versions here come from the release/patch line, so verify against GitLab's own advisory before acting.

CVEs named here

Techniques named here