GitLab shipped emergency patches on September 10 for a maximum-severity path traversal flaw in its repository commits API, and attackers didn’t wait to reverse-engineer it. WatchTowr’s honeypot network logged the first in-the-wild probes at 06:00 UTC on September 11 — less than a day after the advisory went live. CISA added the bug to its Known Exploited Vulnerabilities catalog the same day, with a September 14 remediation deadline for federal agencies.

What happened

CVE-2026-85706 is a CVSS 10.0 path traversal in the API endpoint that serves repository commit information in both GitLab Community Edition and Enterprise Edition. The root cause is improper path confinement combined with missing authentication enforcement: an unauthenticated request to the commits API can be crafted with traversal sequences that walk outside the intended repository directory and pull back arbitrary files from the underlying GitLab server, rather than the repository content the endpoint is supposed to expose.

No credentials, no project access, no user interaction — a single HTTP request against an internet-facing GitLab instance is enough. The flaw was reported by a researcher using the handle “s3ntago” through GitLab’s HackerOne bug bounty program.

GitLab patched two other critical bugs in the same release train, disclosed alongside CVE-2026-85706:

  • CVE-2026-87719 (CVSS 9.9) — an insecure deserialization vulnerability in the GraphQL subscription serializer, EE only.
  • CVE-2026-88765 (CVSS 8.5) — a buffer overflow in EE’s Unicode conversion wrapper, exploitable by an authenticated user who imports a specially crafted Git project export to achieve remote code execution.

The commits API bug is the one under active exploitation and the one that matters most for exposure: it needs no account on the target instance at all.

Affected versions and patches

CVE-2026-85706 affects self-managed GitLab CE and EE across the 18.7 through 19.3 release lines:

  • 18.7 up to (but not including) 19.1.8
  • 19.2 up to (but not including) 19.2.6
  • 19.3 up to (but not including) 19.3.2

GitLab released 19.3.2, 19.2.6, and 19.1.8 on September 10, 2026 to close the hole. GitLab.com and GitLab Dedicated were patched by GitLab directly; this is a self-managed-instance problem. If you’re running an older 18.x line outside the ranges above, check GitLab’s advisory directly — several patch trains were touched simultaneously and version arithmetic across three concurrent branches is easy to get wrong under pressure.

Impact

What an attacker can pull depends on server configuration and filesystem permissions available to the GitLab process, but realistic targets include config/secrets.yml and config/database.yml (Rails secret_key_base and DB credentials), CI/CD runner registration tokens, SSH host keys, and any other file the GitLab web process can read. A secret_key_base leak alone is typically enough to forge session cookies or signed data and escalate to full application compromise; database credentials or CI tokens open a direct path to source code, artifacts, and downstream pipeline compromise. For any org running self-hosted GitLab as its source-of-truth for code and secrets, this is a full instance-compromise primitive delivered pre-auth.

The fact that watchTowr saw structured probing within hours of disclosure — not opportunistic scanning, but requests consistent with a working reproduction — means the window between “patch available” and “mass exploitation” was measured in hours, not days. Any self-managed instance still unpatched as of this writing should be treated as likely already probed, if not compromised.

Mitigation

  • Upgrade immediately to 19.3.2, 19.2.6, or 19.1.8 (or later), matching your current release line.
  • If immediate patching isn’t possible, restrict access to the GitLab instance’s API and web interface to trusted networks/VPN as a stopgap — this bug requires no authentication, so network exposure is the entire attack surface.
  • Rotate secrets.yml secret_key_base, database credentials, CI/CD runner registration tokens, and any SSH host keys if you have any reason to believe the instance was internet-reachable and unpatched between September 10 and your patch time.
  • Review GitLab access and audit logs for anomalous requests to commit/commits API paths containing traversal sequences (../) or unexpected file paths in the days following September 10.
  • Confirm patch status against CISA’s KEV entry if you’re a federal agency or contractor subject to BOD 26-04 — the remediation deadline is September 14, 2026.

Sources: GitLab security release notes, watchTowr Rapid Reaction, CISA KEV catalog addition, BleepingComputer.