Act nowKnown exploited

Advisory · CVE-2026-85706

Unauthenticated GitLab API flaw reads any file on the server

A path traversal flaw in GitLab's repository commits API lets an unauthenticated attacker read arbitrary files from a self-managed server. Fixed in GitLab 19.1.8, 19.2.6, and 19.3.2; CISA confirms active exploitation.

Advisory published September 11, 2026Independent summary
Vendor
GitLab
Product
GitLab
Identifier / CWE
CVE-2026-85706
CWE-22
Action timing
Oct 2, 2026
ELI5

Explain it like I’m five

A library lets visitors request a book by its shelf location, but nobody checks ID badges at the door, and the shelf label can point at a room behind the wall. A stranger can ask for any document in the building and have it handed over.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Crafted request

    An unauthenticated attacker sends an HTTP request to the repository commits API with a file path parameter.

  2. 02Traversal escapes

    Improper path confinement lets the path value escape the intended repository directory.

  3. 03Auth not enforced

    Missing authentication enforcement means no login, token, or session is required.

  4. 04File returned

    The server returns the contents of an arbitrary file, such as configuration, keys, or CI/CD variables.

What happened

GitLab’s September 10, 2026 security release fixed a flaw in the repository commits API: improper path confinement combined with missing authentication enforcement meant that, under certain conditions, an unauthenticated user could read arbitrary files from the GitLab server. GitLab scores it CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N), the maximum severity, and classifies it as path traversal (CWE-22). Affected versions are GitLab CE/EE from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2; the fixed versions are 19.1.8, 19.2.6, and 19.3.2. The flaw was reported by researcher s3ntago through GitLab’s HackerOne program. GitLab.com is already patched and GitLab Dedicated customers need no action; the exposure sits with self-managed installations. watchTowr observed in-the-wild probing starting around 06:00 UTC on September 11, roughly a day after disclosure. CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 11, 2026.

What to do

  1. Upgrade self-managed GitLab CE/EE to 19.1.8, 19.2.6, or 19.3.2 within your current branch; do not wait for a major-version upgrade.
  2. Hunt access logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ carrying a file.Path-style parameter, especially unauthenticated ones, since patch disclosure.
  3. Assume credential exposure if the instance was internet-facing and unpatched during the exposure window: rotate tokens, deploy keys, CI/CD variables, database credentials, and SSH keys readable by the GitLab service account.
  4. If patching is delayed, restrict network access to the GitLab instance to trusted addresses only.

Management note

A GitLab server sits next to source code, deployment keys, CI/CD secrets, and production credentials, so an unauthenticated file read there is a skeleton key to the software supply chain. Probing began within a day of disclosure, and CISA has confirmed active exploitation. Patching closes the hole but cannot un-expose secrets already read, so credential rotation is part of the fix, not an optional extra.