CVE-2026-85706 is a critical, unauthenticated path traversal vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw lives in the repository commits/files API, where a request is allowed to reference a file path that is read from disk before authentication is enforced and without proper confinement to the repository directory. A remote attacker who can reach the API – with no credentials and no user interaction – can read arbitrary files from the GitLab server in a single HTTP request.

Because GitLab servers concentrate an organization’s source code, deploy tokens, CI/CD variables, and connection secrets, a single arbitrary-file-read can expose the material an attacker needs to move laterally, poison pipelines, or compromise downstream systems. GitLab released emergency patches on September 10, 2026; CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog on September 11 after in-the-wild probing was observed within roughly a day of disclosure.

Important: This document is intended for controlled security testing and lab environments. Do not use it against systems you do not own or have explicit permission to test.

The issue is an access-control and path-confinement failure in the repository commits/files API. Three endpoints route file uploads through GitLab Workhorse’s request-body uploader:

POST /api/v4/projects/:id/repository/commits

POST /api/v4/projects/:id/repository/files/:file_path

PUT  /api/v4/projects/:id/repository/files/:file_path

For these routes, GitLab’s Rails handler opens the file referenced by the request-supplied path before the authentication check runs, and without correctly confining that path to the repository’s intended directory. The result is two failures compounding into one critical bug:

1. Missing authentication enforcement – the file is read before authentication is applied, so no valid credentials or session are required.
2. Improper path confinement – the supplied path is not properly restricted, so traversal sequences let the request escape the repository directory and reference arbitrary locations on the server’s filesystem.

Combined, an unauthenticated request can cause GitLab to open and return the contents of a file the GitLab service can read – anywhere the path resolves.

Arbitrary file read on a GitLab server is far more damaging than it sounds, because of what lives on that host. Any file readable by the GitLab process is exposed, which commonly includes:

• GitLab configuration files containing secrets and tokens.
• Application and service logs (which can themselves contain credentials).
• SSH keys, environment files, and database credentials.
• CI/CD variables and deploy tokens.
• Source code and other repository data.

From there, the impact compounds: leaked deploy tokens and CI/CD secrets enable pipeline poisoning and supply-chain compromise, exposed SSH keys and database credentials enable lateral movement, and source-code exposure can reveal further weaknesses. For a platform that sits at the center of an organization’s software delivery, a single unauthenticated file read can be the first link in a full-environment compromise.

The vulnerability affects self-managed GitLab CE and EE. GitLab-managed infrastructure (GitLab.com and GitLab Dedicated) was already patched and requires no action.

All three fixed releases were published on September 10, 2026. The patch release also addressed 17 other vulnerabilities; note that the fixed releases include database migrations (only 19.3.2 carries post-deployment migrations), so single-node installs will see downtime during the upgrade while multi-node deployments can use GitLab’s zero-downtime procedure.

The vulnerable functionality is reached through the repository commits/files API endpoints listed above. The defining characteristics are that no authentication is required and the malicious file path is supplied as part of the request, so a single crafted HTTP request to a reachable GitLab instance is sufficient.

A simplified, conceptual representation of the request looks like:

POST /api/v4/projects/<id>/repository/commits HTTP/1.1

Host: <gitlab-host>

Content-Type: multipart/form-data; boundary=—-x

——x

Content-Disposition: form-data; name=”file.path”

<crafted-path-traversal-to-a-target-file>

——x–

The request-supplied file path is opened server-side before authentication, and because it is not confined to the repository, traversal sequences resolve to files elsewhere on the host. 

Note: The exact working request and traversal encoding should be treated as a lab-testing detail rather than reproduced against production systems; the underlying issue is that the path reaches File.open ahead of the auth check.

At a high level, exploitation follows this path:

he key distinction is that this is a read primitive (confidentiality impact), not direct code execution – but on a GitLab host the files it exposes routinely contain the credentials that can lead to code execution elsewhere.

Defenders should focus on the repository commits/files API and look for unauthenticated or anomalous requests, especially those carrying path-like or traversal-like values.

Potential indicators include:

• Unauthenticated requests to /api/v4/projects/*/repository/commits or /repository/files/*.
• Requests whose parameters contain traversal sequences or absolute paths (../, %2e%2e, leading /), or references to sensitive files.
• Bursts of such requests from a single source, consistent with mass probing (widespread scanning was observed within hours of disclosure).
• Access to configuration, log, or key files by the GitLab service that does not correlate with legitimate activity.
• Post-exploitation signs of credential reuse: unexpected deploy-token or CI/CD-variable use, new SSH sessions, or database access following suspicious API traffic.

Correlate GitLab, reverse-proxy, and web-server logs when investigating. Because CISA’s KEV listing carried forensic-triage expectations, treat any exposed instance as potentially already read and hunt accordingly rather than assuming exposure was only theoretical.

The primary remediation is to upgrade GitLab to a fixed release for your branch, on an emergency basis.

1. Upgrade self-managed GitLab to 19.1.8, 19.2.6, or 19.3.2 (or later) as appropriate for your branch.
2. If you cannot upgrade immediately, restrict access to the repository commits/files API endpoints at a reverse proxy or WAF, and limit network exposure of the GitLab instance.
3. Treat any instance that was internet-exposed on a vulnerable version as potentially compromised. Rotate everything the GitLab process could read – CI/CD variables, deploy tokens, runner registration tokens, SSH keys, database credentials, and secrets in configuration files.
4. Review repository commits/files API access logs for probing or exploitation.
5. Audit for downstream misuse of any credentials that may have been exposed (pipelines, deploy targets, connected systems).
6. Confirm GitLab.com and GitLab Dedicated require no action, and document that for audit.

You can practice exploiting this vulnerability in a controlled environment through the OffSec lab for CVE-2026-85706 in the Offensive Cyber Range, available exclusively on Learn Enterprise. The lab deploys an affected GitLab CE instance so you can demonstrate the unauthenticated arbitrary file read end to end, then confirm the fix on a patched build.

Launch the OffSec lab for CVE-2026-85706

References

• GitLab Critical Patch Release 19.3.2, 19.2.6, 19.1.8 – GitLab Docs
• NVD – CVE-2026-85706
• CVE Record – CVE-2026-85706
• CISA Known Exploited Vulnerabilities Catalog
• watchTowr – Rapid Reaction: GitLab Critical Path Traversal (CVE-2026-85706)
• Rapid7 – CVE-2026-85706: Critical GitLab Path Traversal Exploited in the Wild
• SOC Prime – CVE-2026-85706: Critical GitLab Path Traversal Flaw

CVE-2026-85706 is a critical, unauthenticated path traversal in GitLab’s repository commits/files API that lets an attacker read arbitrary files from a self-managed GitLab server in a single HTTP request. The root cause is a file being opened from a request-supplied path before authentication is enforced and without confinement to the repository directory.

The vulnerability is dangerous because of what a GitLab host stores: secrets, tokens, keys, and source code whose exposure enables lateral movement, pipeline poisoning, and supply-chain compromise. With a CVSS of 10.0, active exploitation confirmed within a day of disclosure, and a KEV listing, self-managed instances should be treated as an emergency.

The safest approach is straightforward: upgrade to 19.1.8 / 19.2.6 / 19.3.2 immediately, restrict access to the affected endpoints until you can, hunt the commits/files API logs for probing, and rotate every credential the GitLab process could have exposed.