TL;DR: GitLab shipped emergency fixes September 10 for CVE-2026-85706, a CVSS 10.0 path traversal in the repository commits API. watchTowr observed in-the-wild probes within hours, and CISA added it to the KEV catalog the next day with a three-day deadline. Self-managed GitLab instances need to upgrade now.

The Vulnerability

CVE-2026-85706 lives in GitLab’s repository commits API. Under certain conditions, an unauthenticated user can request arbitrary files from the GitLab server via improper path confinement and missing authentication enforcement.

GitLab’s CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N — network attack, no auth needed, changed scope, high impact on confidentiality and integrity.

The critical constraint: exploitation requires at least one publicly accessible project with repository access enabled on the target instance. No public projects = no attack surface.

Affected Versions

  • All versions from 18.7 before 19.1.8
  • All versions from 19.2 before 19.2.6
  • All versions from 19.3 before 19.3.2

Fixed versions released September 10, 2026. GitLab.com was already patched; GitLab Dedicated customers do not need to act.

The Timeline

  • September 10: GitLab publishes fixed versions (19.1.8, 19.2.6, 19.3.2)
  • September 11, ~06:00 UTC: watchTowr’s Attacker Eye honeypot detects behavioral probes targeting the vulnerable API
  • September 11: CISA adds CVE-2026-85706 to the KEV catalog with due date September 14, 2026 (three days)
  • September 11: NVD publishes the CVE record (CVE-2026-85706)

The entire window from patch release to KEV listing is roughly 24 hours. The fix was available before the first known probe hit watchTowr’s network — organizations that upgrade immediately on patch day face zero exposure.

What Gets Read

Successful exploitation exposes files readable by the GitLab process:

  • Configuration files containing credentials and secrets
  • .env files, SSH keys, database credentials
  • CI/CD variables and deploy tokens
  • Log files with embedded tokens
  • Source code from public repositories

For internet-facing self-managed instances, access to CI/CD secrets can cascade into downstream infrastructure compromise — unauthorized repo pushes, artifact manipulation, or credential reuse against cloud providers.

Detection

watchTowr’s indicator focuses on the request structure rather than a specific path string. Look for unusual file.Path parameters in commits API requests that reference files outside the expected repository directory:

GET /api/v4/projects/:id/repository/commits/:sha/blobs
  ?file_path=../../../etc/gitlab-secrets.json

Check access logs for paths starting with ../ or files with extensions unusual for the repository (e.g., .json, .yml, .env in a Go project).

The Broader Picture

This patch release also fixed 17 other CVEs, including CVE-2026-87719 (CVSS 9.9, insecure deserialization in GitLab EE’s Duo Chat GraphQL paths). Only CVE-2026-85706 is known exploited in the wild. The release was credited to researcher s3ntago via GitLab’s HackerOne program.

What to Check

  1. Inventory: Find all self-managed GitLab CE/EE instances
  2. Version check: Confirm which version line each instance runs
  3. Upgrade: Move to 19.1.8, 19.2.6, or 19.3.2 (or later)
  4. Monitor: Check access logs for suspicious file.Path parameters in commits API calls
  5. Rotate: If the instance was exposed before patching, rotate credentials, tokens, and deploy secrets found in exposed files

For single-node deployments, expect downtime during database migrations. Multi-node deployments can use GitLab’s zero-downtime upgrade procedure. Only 19.3.2 includes post-deployment migrations.

Sources