CVE-2026-85706: GitLab CVSS 10.0 Path Traversal Under Active Probing

If you run a self-managed GitLab instance that is reachable from the internet, you should treat this as an emergency patch event. GitLab has shipped fixes for a maximum-severity vulnerability — CVE-2026-85706 (CVSS 10.0) — a path traversal flaw in the repository commits API that allows an unauthenticated attacker to read arbitrary files from the underlying server. Within hours of public disclosure, security researchers observed in-the-wild probing against exposed instances.

This is the worst possible combination of attributes for a defensive team: no authentication required, a trivially scriptable HTTP request as the exploitation vehicle, a target platform that by design stores source code, CI/CD secrets, signing keys, and deploy tokens, and a threat actor community that began scanning before many change-advisory boards had even convened.

A CVSS 10.0 unauthenticated file read on a GitLab server is not just a confidentiality bug. Read access to /etc/gitlab/gitlab.rb , Rails secret files, database credentials, Gitaly configuration, or stored SSH keys converts a file-read primitive into full instance compromise — and from there, into a software supply-chain foothold against every project and pipeline that server touches. We have seen this movie before with CI/CD platforms; the difference between an incident and a headline is how fast you patch and how well you can prove you were not hit first.

Vulnerability Overview

The repository commits API endpoint ( GET /api/v4/projects/:id/repository/commits ) accepts parameters that are ultimately used to construct filesystem paths when GitLab resolves repository data through Gitaly. The vulnerable code path fails to properly canonicalize or sandbox attacker-controlled path components. By supplying traversal sequences — ../ , URL-encoded variants ( %2e%2e%2f , %252e%252e%252f for double-encoding), or mixed-encoding forms — an unauthenticated remote requester can escape the intended repository directory and coax the server into returning the contents of arbitrary files readable by the git service account.

Key exploitation characteristics from a defender's perspective:

Single GET request. No session, token, CSRF dance, or multi-stage setup. One malformed API call returns file contents in the response body.

High-value target files. Attackers typically reach for /etc/gitlab/gitlab.rb (can contain secrets depending on configuration), /etc/gitlab/gitlab-secrets.json (Rails secret_key_base, OTP and DB encryption keys — effectively the keys to the kingdom), /var/opt/gitlab/gitlab-rails/etc/database.yml , user SSH authorized_keys, and CI/CD variable stores.

The gitlab-secrets.json scenario is the nightmare path. With secret_key_base and related encryption keys, an attacker can forge sessions and decrypt database-encrypted secrets. This pivots the bug from "file read" to "unauthenticated admin."

Noisy at the edge, quiet on the host. Exploitation is pure HTTP traffic to the nginx/Puma front end. There is no process execution on the server until a post-exploitation stage, which means your detection lives in web/API logs — not EDR process telemetry.

Per reporting, probes began within hours of the advisory going public. That timeline is consistent with what we observe for CVSS 10 pre-auth bugs on developer infrastructure: scanners (both researcher-operated and criminal) fingerprint exposed GitLab instances by version banner and fire traversal payloads at the commits API. Assume that any internet-exposed, unpatched instance has already been enumerated. Even if your instance requires login for projects, pre-auth API paths are reachable before authentication — do not assume an "internal users only" stance protects an internet-facing instance.

Because exploitation is an HTTP-layer event, your primary telemetry sources are: GitLab nginx access logs ( /var/log/gitlab/nginx/gitlab_access.log ), GitLab Rails API logs ( /var/log/gitlab/gitlab-rails/api_json.log ), upstream WAF/reverse-proxy logs, and any CEF/Syslog forwarding you have into Sentinel or your SIEM. The detections below target the observable signature of this attack: traversal sequences — raw or encoded — in request URIs against the repository commits API.

1. Patch immediately — this is a same-day event. GitLab has released patched versions for CVE-2026-85706 and the other flaws addressed in the same release cycle. Upgrade all self-managed GitLab CE/EE instances to the latest security release published at GitLab Security Releases and confirm against the official advisory for CVE-2026-85706 in the GitLab security advisories portal . Verify your running version with gitlab-rake gitlab:env:info and compare against the fixed versions listed in the advisory. Do not wait for a maintenance window — exploitation is already occurring.

2. If you cannot patch within hours, remove the attack surface. Take the instance off the internet or place it behind an authenticating reverse proxy/VPN. As a temporary mitigation, block requests matching traversal patterns at your WAF or reverse proxy (reject URIs containing ../ , %2e%2e , %252e , ..%2f in any /api/v4/ path). This is a compensating control, not a fix — WAF rules can be bypassed with novel encodings, and the patch is the only complete remediation.

3. Assume compromise for internet-exposed unpatched instances and hunt before you celebrate. The probing window opened within hours of disclosure. Grep historical nginx access logs (including rotated .gz archives) for the patterns in the script above. Any 200-response traversal hit against the commits API means a file was read — determine which file from the URI and scope accordingly.

4. Rotate secrets if there is any evidence of successful exploitation. Specifically: regenerate the contents of /etc/gitlab/gitlab-secrets.json (followed by gitlab-ctl reconfigure ), rotate the database password, reset all personal access tokens, deploy tokens, runner registration tokens, CI/CD variables containing credentials, and any SSH keys stored on the server. Audit audit_json.log for token creation, project exports, or membership changes you cannot explain. If secret_key_base was exposed, every session and encrypted secret in the instance must be considered compromised.

5. Harden going forward. Enforce IP allowlisting or SSO-fronted access for the API where feasible, ensure nginx access and Rails API logs are forwarded to your SIEM with at least 90-day retention, and enable GitLab's audit event streaming. Add version-banner monitoring: GitLab exposes /api/v4/version unauthenticated by default on many configurations — restricting it reduces your visibility to opportunistic scanners. Finally, track this class of bug in your vulnerability management program with a severity-based SLA: CVSS 10.0 pre-auth flaws on internet-facing developer infrastructure get patched in 24 hours, full stop.

Developer infrastructure is production infrastructure. An unauthenticated 10.0 file-read on your source-of-truth for code, secrets, and pipelines is a supply-chain risk event, not a routine patch. Patch today, hunt your logs going back to before the disclosure date, and rotate secrets if you find hits.

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.