GitLab Fixes Critical Path Traversal Flaw That Could Expose Arbitrary Server Files

GitLab has disclosed and remediated a critical path traversal vulnerability, CVE-2026-85706, affecting GitLab Community Edition (CE) and Enterprise Edition (EE).

The vulnerability carries a CVSS 3.1 score of 10.0, the highest possible severity rating. According to GitLab's security advisory, the flaw could, under certain conditions, allow an unauthenticated user to read arbitrary files from the GitLab server.

The issue was caused by improper path confinement combined with missing authentication enforcement in the repository commits API.

What is CVE-2026-85706?

CVE-2026-85706 is classified as CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as a path traversal vulnerability.

Path traversal vulnerabilities occur when an application does not properly restrict file paths to an intended directory. In vulnerable implementations, specially constructed paths can potentially cause an application to access files outside the directory it was supposed to use.

In this case, GitLab says the problem affected its repository commits API. The combination of inadequate path confinement and missing authentication enforcement created a condition in which an unauthenticated user could potentially access arbitrary files on the GitLab server.

The company has not disclosed additional technical exploitation details in the public advisory beyond this description.

Why the vulnerability is rated Critical

The vulnerability has a CVSS 3.1 score of 10.0, with the following vector:

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

The rating indicates that the issue is remotely reachable, requires low attack complexity, does not require privileges or user interaction, and can have a significant impact on confidentiality and integrity.

The CVE record identifies the affected weakness as CWE-22.

Importantly, the advisory does not state that the vulnerability has been actively exploited in the wild.

It also does not provide evidence that attackers successfully accessed particular customer environments.

Which GitLab versions are affected?

GitLab identifies the following affected version ranges:

The patched releases are therefore:

• 19.1.8

• 19.2.6

• 19.3.2

GitLab's critical patch release documentation confirms that these versions contain the remediation for CVE-2026-85706.

What should GitLab administrators do?

Organisations operating self-managed GitLab CE or EE should review their deployed version and upgrade to a patched release if they are running an affected version.

GitLab's patch-release guidance recommends upgrading self-managed installations to the appropriate patched release. GitLab.com customers do not manage the underlying GitLab infrastructure themselves.

Administrators should prioritise version verification because the vulnerability does not require authentication under the conditions described by GitLab.

A sensible response process is:

1. Identify the deployed GitLab version.

2. Determine whether it falls within an affected range.

3. Upgrade to 19.1.8, 19.2.6 or 19.3.2, as appropriate.

4. Review relevant server and application logs for unexpected repository API activity.

5. Investigate any anomalous file-access or API behaviour according to the organisation's incident-response procedures.

The public advisory does not provide specific indicators of compromise or a confirmed exploitation campaign.

How the vulnerability fits into GitLab's security release process

GitLab publishes security fixes through its patch-release process. The company distinguishes between scheduled releases and ad-hoc critical patches for high-severity vulnerabilities.

GitLab also operates as a CVE Numbering Authority. Its CNA scope includes the GitLab application and certain vulnerabilities affecting projects hosted on GitLab.com.

For CVE-2026-85706, GitLab credits s3ntago for reporting the vulnerability through its HackerOne bug bounty programme.

Security impact for DevSecOps teams

The vulnerability is particularly relevant to organisations running GitLab as a self-managed development and DevSecOps platform.

GitLab environments can contain sensitive development assets, configuration information and other server-side data. A vulnerability capable of arbitrary file disclosure therefore warrants prompt investigation even when there is no public confirmation of exploitation.

The CVE's combination of network accessibility and lack of required privileges makes version management especially important.

For security teams, the incident also demonstrates why vulnerability management should cover the DevOps platform itself, not only the applications and dependencies hosted on it.

What is known and what is not known

The publicly available information establishes several points:

• CVE-2026-85706 is a path traversal vulnerability.

• It affects GitLab CE and EE.

• The issue involves the repository commits API.

• GitLab says an unauthenticated user could, under certain conditions, read arbitrary files from the GitLab server.

• The vulnerability has a CVSS score of 10.0.

• Versions before 19.1.8, 19.2.6 and 19.3.2 in the specified branches are affected.

• GitLab has released fixes.

• The vulnerability was reported through GitLab's HackerOne bug bounty programme.

However, the available advisory does not establish:

• confirmed exploitation in the wild

• confirmed customer compromises

• a public proof of concept

• specific malicious payloads

• specific stolen files

• an attacker campaign associated with the vulnerability

Why this matters

The broader lesson is that security controls around developer infrastructure are as important as those protecting production applications.

A vulnerability in a repository-management platform can potentially expose information outside the immediate application functionality when server-side file handling and access controls fail.

For enterprises, this could mean that DevSecOps platform patching should be treated as an operational security priority, particularly for internet-facing self-managed installations.

The development also reflects the importance of combining vulnerability disclosure programmes, security testing and rapid patch releases in software-development infrastructure.