GitLab Has a CVSS 10 Path Traversal. Anonymous Attackers Can Read Server Files

• The Mess: GitLab patched a CVSS 10.0 path traversal in the Repository Commits API that can expose arbitrary files to an unauthenticated remote attacker.
• The Damage: A GitLab server can leak configuration, credentials, tokens, and other sensitive files before the attacker ever needs an account.
• The Fix: Upgrade GitLab CE/EE immediately to 19.3.2, 19.2.6, or 19.1.8, depending on your release branch.

CVE-2026-85706 is the kind of GitLab vulnerability administrators do not want sitting on an Internet-facing instance.

The flaw lives in the repository commits API. GitLab describes the issue as a combination of missing authentication enforcement and improper path confinement. Under certain conditions, an attacker can escape the intended repository path and make the server return arbitrary files from its filesystem.

There is no authentication requirement in the published CVSS vector:

CVSS 10.0 — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

That translates into a remote attack with low complexity, no account, no user interaction and high confidentiality impact. The scope also changes, which is one reason the score reaches the maximum.

Why GitLab Servers Are Interesting Targets

GitLab is rarely just a web application.

A self-managed installation can hold source code, CI/CD configuration, runner information, deployment credentials, API tokens, registry credentials and configuration files containing secrets. GitLab’s own hardening guidance specifically recommends protecting CI/CD variables, runners, tokens and other sensitive project resources because compromise of one component can expand into the software supply chain.

An arbitrary file-read primitive therefore has a much larger potential impact than simply exposing /etc/hostname.

An attacker who can retrieve sensitive GitLab configuration may obtain material that can be reused against the GitLab instance, repositories, CI infrastructure or connected cloud services.

The vulnerability is particularly unpleasant because the first step does not require stealing a GitLab account.

A Narrow Patch Window

GitLab fixed CVE-2026-85706 in:

• 19.3.2
• 19.2.6
• 19.1.8

Affected releases include GitLab CE/EE versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The patched container images were published on September 10.

GitLab’s security process recommends upgrading self-managed installations to the latest security release. GitLab.com and GitLab Dedicated are managed by GitLab and are already protected by the vendor’s infrastructure.

What Administrators Should Do

Patch first.

Then review access logs around the GitLab API for unusual requests involving repository commit endpoints, traversal sequences or unexpected attempts to retrieve filesystem resources.

If the server was exposed to the Internet while running a vulnerable version, do not assume that patching alone closes the incident. Rotate credentials and tokens that could have been present in readable configuration or CI/CD material, and investigate suspicious authentication and runner activity.

GitLab itself recommends restricting sensitive CI/CD variables, protecting runners and limiting token access to reduce the blast radius of a compromised instance.

There is another uncomfortable detail: GitLab normally keeps vulnerability reports private for 90 days after a fix, meaning the technical disclosure window can lag behind the patch release.

For administrators, that means the safest strategy is simple: patch before someone starts reverse-engineering the fix.

Bugstoday Opinion

A CVSS 10 path traversal in software that stores source code and deployment secrets is exactly the kind of bug that deserves an emergency maintenance window.

No password. No victim clicking anything. Just an exposed GitLab instance running the wrong build.

GitLab has shipped the fix. Now the interesting question is how many self-managed servers will still be running the vulnerable version next week.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

GitLab Security

GitLab CVE Numbering Authority

GitLab Security FAQ

GitLab Hardening Guide

CVE-2026-85706