GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.1.8

CVE-2026-85706 is a path traversal vulnerability in the GitLab CE/EE repository commits API (/api/v4/projects/{id}/repository/commits/). By sending a crafted HTTP POST request with a manipulated file.path parameter, an unauthenticated attacker can read arbitrary files from the underlying server — configuration files, SSH keys, CI/CD secrets, database credentials, and anything else the git process user can access. The flaw is rooted in improper path confinement combined with missing authentication enforcement on the affected endpoint. All self-managed GitLab CE/EE versions from 18.7 through 19.1.7, 19.2.0–19.2.5, and 19.3.0–19.3.1 are vulnerable. Fixed versions are 19.1.8, 19.2.6, and 19.3.2, released September 10, 2026.

The vendor CVSS of 10.0 is completely justified and noisgate agrees. There is zero friction in this chain: no authentication, no user interaction, no elevated privileges, network-reachable from the internet in the majority of self-managed deployments. watchTowr confirmed active exploitation probes began at 06:00 UTC on September 11 — less than 24 hours after the patch shipped — and CISA added it to the KEV catalog the same week. The affected component is a CI/CD server that by definition holds source code, secrets, and deployment credentials. This is a supply-chain-class vulnerability and the 10.0 is earned.

Why this verdict

• Zero authentication barrier: The commits API endpoint requires no credentials, tokens, or session — a single curl command from the internet exploits it. No friction to discount.
• Role multiplier — CI/CD supply-chain server: GitLab self-managed is, by definition, a supply-chain-critical component. ≥90% of self-managed GitLab installations serve as the primary CI/CD platform for their organization. Compromise yields source code, CI/CD secrets, deploy keys, runner tokens, and pipeline injection capability. Blast radius: supply-chain-scale. This sets the verdict floor at CRITICAL.
• Active exploitation with KEV listing: Attackers reverse-engineered the patch within 24 hours. CISA KEV confirms in-the-wild exploitation. Over 20,000 instances are internet-reachable per Shodan/Censys, with ~1,400 still running vulnerable versions.
• Trivial exploit complexity: No public PoC needed — the attack is a single HTTP POST with path traversal in file.path. Any script kiddie with a curl one-liner can exfiltrate gitlab-secrets.json.

Why not higher?

A 10.0 is the maximum CVSS score. There is no higher severity bucket than CRITICAL. The vendor assessment is accurate and noisgate has no room to upgrade further.

Why not lower?

Every downgrade factor was evaluated and none apply. The attack is unauthenticated (no auth friction), network-reachable (no internal-only friction), low complexity (no chaining friction), and the target component is canonically a high-value CI/CD server where ≥90% of installs occupy a supply-chain-critical role. The role-multiplier floor rule locks this at CRITICAL regardless. Active KEV exploitation removes any theoretical-only discount. There is no legitimate basis to downgrade.

1. Block unauthenticated access to the commits API at the reverse proxy or WAF — Add a rule to your reverse proxy (nginx, HAProxy, Cloudflare, AWS ALB) blocking unauthenticated POST requests to /api/v4/projects/*/repository/commits/ immediately. This is the fastest mitigation if you cannot patch within hours. Deploy within the noisgate mitigation SLA of ≤ 3 days for CRITICAL, though given active exploitation, deploy within hours.
2. Restrict GitLab to VPN or zero-trust access only — If your GitLab instance is internet-facing, place it behind a VPN, ZTNA gateway, or IP allowlist immediately. This eliminates the unauthenticated remote attack vector entirely. Given KEV status, do this today.
3. Rotate all secrets stored in GitLab — After patching, rotate all CI/CD variables, runner registration tokens, deploy keys, SSH keys, SMTP credentials, LDAP bind passwords, and the Rails secret key base in gitlab-secrets.json. Assume compromise if the instance was internet-facing and unpatched between September 10–12. Complete within 72 hours of patching.
4. Audit logs for exploitation indicators — Review GitLab production logs (gitlab-rails/production.log) for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ containing file.path parameters with traversal sequences (../). Forward to your SIEM for retrospective analysis from September 10 onward.
5. Apply the vendor patch — Upgrade to GitLab 19.3.2, 19.2.6, or 19.1.8 per the noisgate remediation SLA of ≤ 90 days for CRITICAL — though given active exploitation, patch immediately, within hours if possible.

Run this script on the GitLab server itself (or from any host with curl access to the GitLab instance). Invoke as: bash check_cve_2026_85706.sh https://gitlab.example.com. No special privileges required — it checks the installed GitLab version via the public API.

#!/usr/bin/env bash
# check_cve_2026_85706.sh — Check GitLab for CVE-2026-85706 (path traversal in commits API)
# Usage: bash check_cve_2026_85706.sh <GITLAB_URL>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

GITLAB_URL="${1:?Usage: $0 <GITLAB_URL>}"
GITLAB_URL="${GITLAB_URL%/}"

echo "[*] Checking GitLab version at ${GITLAB_URL}..."

# Fetch version from the public metadata endpoint
VERSION_JSON=$(curl -sk --max-time 10 "${GITLAB_URL}/api/v4/version" 2>/dev/null || true)

if [ -z "$VERSION_JSON" ]; then
  # Try the unauthenticated metadata endpoint
  VERSION_JSON=$(curl -sk --max-time 10 "${GITLAB_URL}/api/v4/metadata" 2>/dev/null || true)
fi

if [ -z "$VERSION_JSON" ]; then
  echo "[!] Could not retrieve GitLab version. The API may require authentication."
  echo "[*] Trying to parse version from the login page..."
  LOGIN_PAGE=$(curl -sk --max-time 10 "${GITLAB_URL}/users/sign_in" 2>/dev/null || true)
  VERSION=$(echo "$LOGIN_PAGE" | grep -oP 'GitLab (Community|Enterprise) Edition \K[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  if [ -z "$VERSION" ]; then
    echo "UNKNOWN — could not determine GitLab version"
    exit 2
  fi
else
  VERSION=$(echo "$VERSION_JSON" | grep -oP '"version"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+' | head -1)
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse GitLab version"
  exit 2
fi

echo "[*] Detected GitLab version: ${VERSION}"

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

VULNERABLE=0

# Affected: 18.7+ through 19.1.7, 19.2.0-19.2.5, 19.3.0-19.3.1
if [ "$MAJOR" -eq 18 ] && [ "$MINOR" -ge 7 ]; then
  VULNERABLE=1
elif [ "$MAJOR" -eq 19 ]; then
  if [ "$MINOR" -eq 0 ]; then
    VULNERABLE=1
  elif [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 8 ]; then
    VULNERABLE=1
  elif [ "$MINOR" -eq 2 ] && [ "$PATCH" -lt 6 ]; then
    VULNERABLE=1
  elif [ "$MINOR" -eq 3 ] && [ "$PATCH" -lt 2 ]; then
    VULNERABLE=1
  fi
fi

if [ "$VULNERABLE" -eq 1 ]; then
  echo "VULNERABLE — GitLab ${VERSION} is affected by CVE-2026-85706"
  echo "[!] Upgrade immediately to 19.1.8, 19.2.6, or 19.3.2"
  exit 1
else
  echo "PATCHED — GitLab ${VERSION} is not in the affected version range"
  exit 0
fi

Sources

1. Horizon3 – CVE-2026-85706 Technical Analysis
2. watchTowr – Rapid Reaction: GitLab Critical Path Traversal
3. BleepingComputer – GitLab Urges Users to Patch Max Severity Flaw
4. SecurityWeek – GitLab Vulnerability Exploited One Day After Disclosure
5. CyberScoop – GitLab's Critical Flaw Draws Internet-Wide Probes
6. CISA – GitLab Path Traversal Vulnerability Exploited in Attacks
7. The Hacker News – GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes
8. SecurityOnline – GitLab Vulnerabilities CVE-2026-85706 CVSS 10.0