TL;DR

CVE-2026-85706 is a CVSS 10.0 path traversal in the GitLab repository commits API. An unauthenticated attacker sends a crafted POST to the commits endpoint with a file.path parameter that breaks out of the restricted directory and reads arbitrary files — config files, .env, credentials, anything the GitLab process can access. CISA added it to the Known Exploited Vulnerabilities catalog on September 14, 2026, with a same-day remediation deadline. Exploitation was observed within 24 hours of disclosure. If you run self-managed GitLab, you’re on the clock.

The vulnerability

GitLab disclosed CVE-2026-85706 (CVSS 10.0) on September 10, 2026. The flaw lives in the repository commits API — specifically the endpoint that fetches file contents from a commit. Under certain conditions, the API performs improper path confinement and does not enforce authentication before returning the file.

An attacker sends a POST to the commits API with a file.path parameter like ../../../../etc/passwd or ../../config/gitlab.yml and gets the file back — no auth required. The CNA-assigned vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N — network, low complexity, no privileges, scope changed, high confidentiality impact.

The researcher who found it, s3ntago, reported it via GitLab’s HackerOne bug bounty program (report #3909881). GitLab linked the work item as 627748 in their issue tracker.

Why the commits API

The repository commits API is a public-facing endpoint: you don’t need to be logged in to request file contents from a public project’s commit tree. The vulnerability surfaces when the API accepts a file.path parameter and resolves it against the project’s storage directory. If the parameter contains path traversal sequences, and the resolved path falls outside the project root but still within the GitLab server’s accessible tree, the file gets returned.

What makes this worse than a normal path traversal: the commits API is routinely hit by scanners, CI systems, mirrors, and bots. An attacker doesn’t need to know your repo structure to find the endpoint — it’s at a predictable URL for every public (and many private) project. And because it’s a high-traffic path, you can blend exploitation in with normal traffic.

Exploitation signature

WatchTowr noted the detection signal: a POST to the commits API with a file.path parameter containing ../ sequences. In practice, the signature looks like:

POST /<group>/<project>/-/api/v4/repository/commits/<sha>/tree HTTP/1.1
Host: gitlab.example.com

file.path=../../../../../../etc/passwd

or similar, depending on the exact endpoint variant. The file.path parameter is the key — a normal request uses it to specify a file inside the commit. A traversal request uses it to escape the commit’s directory.

Affected and fixed

GitLab patched the flaw in their September 10 critical patch release:

Version line Affected (before) Fixed in
19.3 19.3 before 19.3.2 19.3.2
19.2 19.2 before 19.2.6 19.2.6
19.1 19.1 before 19.1.8 19.1.8
18.7 18.7 before 19.1.8 19.1.8

GitLab CE and EE are both affected. GitLab.com (SaaS) is patched. The vulnerable lines start at 18.7 — anything from that release onward, below the fixed patch level, is in scope.

CISA KEV — due September 14

CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog on September 14, 2026, with a due date of September 14, 2026 — meaning CISA considered it urgent enough that federal agencies needed to patch the same day it was added. This is unusual for a KEV due date (typical is 28-30 days out) and reflects how quickly exploitation hit.

Supply-chain angle

A path traversal against the commits API isn’t just a file read — it’s a supply-chain primitive. If you’re reading .gitlab-ci.yml, docker-compose.yml, requirements.txt, or any config file that contains secrets, API keys, or build parameters, you’ve turned the traversal into a credential dump. And if the attacker can reach the repository storage directly, they can read files from other projects that share the same storage tree — a cross-project file read from a single HTTP request.

What to do

  1. Check your GitLab version. Self-managed instances on any version from 18.7 up to (but not including) the fixed patch level are vulnerable. gitlab-rake gitlab:env:info or the admin panel version check.
  2. Upgrade to the fixed patch. 19.3.2 / 19.2.6 / 19.1.8 depending on your branch. This is the primary fix — no partial workaround.
  3. Hunt the commits API logs. POST requests with file.path containing ../ or ..%2F in the hours after September 10. Look at the response size and status code — a traversal that hits an interesting file will return a non-empty body.
  4. Check for cross-project reads. If your GitLab stores projects in a shared directory, a traversal past the project root might expose sibling projects’ files. Check ../../ and ../../../ responses.
  5. Rotate secrets found in any files the traversal can reach — .env, database.yml, secrets.json, CI variables stored in config files.

The pattern

This is the same class of bug that keeps appearing in GitLab: the commits API (or a related file-serving endpoint) accepts external path input and doesn’t confine it tightly enough. The fix is always the same — validate the resolved path against the project root and reject anything that escapes. The reason it keeps appearing is that GitLab’s API surface is large and the commits endpoint is a natural target for mirrors, CI integrations, and third-party tools — which means it’s a natural target for attackers too.

The lesson isn’t new: public file-serving APIs need a realpath check or equivalent, not just a prefix check. A prefix check (path.startsWith(project_root)) survives traversal if the input is ../../../project_root/subdir/file. A realpath check (os.path.realpath(user_path).startswith(project_root)) is the reliable fix.

The takeaway

Patch the commits API, check the logs for the file.path POST signature, rotate anything the traversal could have reached. The KEV due date was same-day because exploitation was already in the wild — and because the target (GitLab, the de facto source-of-truth for most development teams) means the supply-chain impact is broader than the single-server compromise.

References