CVE-2026-85706: Critical GitLab Path Traversal Flaw Exploited in the Wild

GitLab has released emergency security updates for a maximum-severity vulnerability in Community Edition (CE) and Enterprise Edition (EE) that allows unauthenticated attackers to read arbitrary files from vulnerable servers. Tracked as CVE-2026-85706 and rated 10.0 on the CVSS scale, the flaw resides in the repository commits API and results from improper path confinement combined with missing authentication enforcement.

The risk escalated almost immediately after disclosure. Security researchers observed internet-wide probing beginning at approximately 06:00 UTC on September 11, 2026, shortly after GitLab released patches. CISA subsequently added the vulnerability to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation.

Successful exploitation can expose sensitive files stored on the GitLab server, including configuration data, credentials, secrets, logs, and other information accessible to the GitLab service. In development environments, those files may contain CI/CD secrets, deployment credentials, tokens, source-code-related data, and information that could support follow-on compromise.

The flaw is particularly dangerous for internet-facing self-managed GitLab installations because exploitation does not require an account, existing privileges, or user interaction. According to watchTowr, the primary prerequisite for the observed attack path is that the GitLab instance contains at least one public project.

CVE-2026-85706 analysis

The vulnerability is a path traversal issue in GitLab’s repository commits API. GitLab describes the root cause as insufficient confinement of file paths combined with failure to enforce authentication on the affected functionality. This allows attacker-controlled path information to escape the location where GitLab expects repository files to reside and reference other files available to the application.

The CVSS vector assigned by GitLab is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. It reflects a remotely exploitable vulnerability with low attack complexity, no authentication requirement, and no user interaction. GitLab assigns high confidentiality and integrity impacts, while availability is not directly affected by the file-read primitive itself.

The most important details for CVE-2026-85706 are that attackers can interact with the vulnerable repository commits API remotely and request paths that should fall outside the permitted repository directory. If GitLab fails to contain that path correctly, the server can return the contents of an arbitrary file accessible to the GitLab process.

According to watchTowr, exploitation can expose GitLab-specific configuration and log files containing credentials, secrets, and other sensitive information. Depending on system configuration and file permissions, attackers may also target SSH keys, environment files, database credentials, deploy tokens, or other sensitive application data.

CVE-2026-85706 affects the following GitLab CE and EE releases:

• All versions from 18.7 before 19.1.8
• All versions from 19.2 before 19.2.6
• All versions from 19.3 before 19.3.2

GitLab.com was already running the patched version when the issue was disclosed, while GitLab Dedicated customers do not need to take action. The urgent remediation requirement primarily applies to organizations operating self-managed GitLab instances.

The requirement for at least one public project significantly increases the exposure of organizations that intentionally host open-source repositories, public development projects, community resources, or other anonymously accessible content on their own GitLab infrastructure. An attacker does not need membership in the project or a valid GitLab account before attempting exploitation.

The consequences can extend beyond simple information disclosure. GitLab frequently sits at the center of software development pipelines and stores highly sensitive material, including source code, CI/CD variables, deploy credentials, infrastructure configuration, access tokens, and integration secrets.

If an attacker obtains such credentials through arbitrary file access, the initial GitLab vulnerability can become a stepping stone for additional intrusion activity. Stolen secrets could potentially provide access to source-code repositories, CI/CD infrastructure, cloud services, container registries, deployment systems, or other connected resources.

This also introduces a software supply-chain risk. Access to development credentials or build infrastructure could enable an attacker to attempt unauthorized repository changes, manipulate build processes, steal proprietary code, or compromise downstream systems that trust artifacts produced through the affected GitLab environment.

GitLab credited security researcher s3ntago with reporting the vulnerability through the company’s HackerOne bug bounty program. The exact private discovery and report date has not been publicly disclosed. GitLab released fixed versions on September 10, 2026 and publicly documented the flaw as part of its critical patch release.

The transition from disclosure to hostile activity was extremely rapid. WatchTowr said its Attacker Eye honeypot network detected behavioral probes targeting the vulnerability from approximately 06:00 UTC on September 11, indicating that external actors had already reverse-engineered the weakness and begun testing internet-accessible GitLab systems.

CISA added the flaw to its KEV catalog later on September 11 after confirming evidence of active exploitation. Federal Civilian Executive Branch agencies were instructed to remediate affected systems by September 14, 2026, and CISA also marked the vulnerability as requiring forensic triage under Binding Operational Directive 26-04.

Public CVE-2026-85706 PoC code also appeared soon after disclosure, further lowering the technical barrier for attackers interested in reproducing the arbitrary-file-read behavior. Combined with the vulnerability’s low complexity and unauthenticated attack path, public reproduction increases the likelihood of broader opportunistic exploitation.

There is currently no comprehensive set of campaign-specific CVE-2026-85706 IOCs such as attacker IP addresses, domains, or malware hashes that can reliably identify exploitation. Instead, the most useful indicator is the structure of requests targeting the vulnerable GitLab API.

WatchTowr recommends looking for HTTP POST requests directed at paths matching:

/api/v4/projects/{id}/repository/commits/

Defenders should pay particular attention when those requests contain suspicious file.Path parameters or appear to request files unrelated to the repository being accessed.

CVE-2026-85706 Mitigation

GitLab strongly recommends that all affected self-managed installations upgrade immediately to one of the fixed releases:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Any later supported release containing the security fix should also address the vulnerability. Administrators should verify the exact running version rather than assuming automatic updating has occurred.

Organizations unable to patch immediately should remove unnecessary public access to the affected GitLab instance or restrict connectivity at the reverse proxy, firewall, load balancer, or network layer until the upgrade can be completed. This is only a temporary exposure-reduction measure and should not replace installation of GitLab’s fixed release.

CVE-2026-85706 detection should start with identifying all self-managed GitLab instances, their exact versions, and whether they were accessible from the internet after September 10. Systems hosting one or more public projects should receive particularly high investigation priority.

To Detect CVE-2026-85706 exploitation or reconnaissance, defenders should review GitLab, reverse-proxy, WAF, and web-server telemetry for:

• HTTP POST requests to /api/v4/projects/{id}/repository/commits/
• Requests containing unusual file.Path parameters
• Path traversal sequences attempting to leave expected repository directories
• Requests for GitLab configuration or log files through repository APIs
• Large numbers of repository commits API requests from previously unseen sources
• Anonymous access followed by unusual attempts to retrieve server-side resources
• Unexpected access to credentials, configuration files, or application secrets
• New authentication activity using credentials that may have been exposed through GitLab
• Unexplained access to CI/CD, cloud, registry, or deployment infrastructure following suspicious GitLab activity

WatchTowr specifically recommends reviewing the repository commits API pattern because it can provide direct evidence of probing or exploitation attempts against the vulnerable endpoint.

Patching should also be combined with retrospective investigation. CISA’s requirement for forensic triage reflects the possibility that organizations may have been compromised before deploying the fix, particularly given how quickly attacks began after disclosure.

If suspicious file-read activity is identified, administrators should determine exactly which files may have been accessed. Secrets contained in potentially exposed files should be considered compromised until proven otherwise.

Organizations should consider rotating:

• GitLab access and personal access tokens
• Deploy tokens
• CI/CD variables and secrets
• Database credentials
• SSH keys
• Cloud credentials
• Container registry credentials
• API and integration tokens
• OAuth secrets
• Deployment and automation credentials

Security teams should also investigate downstream systems that trusted those credentials. Updating GitLab closes the vulnerable file-read path but cannot invalidate secrets already obtained by an attacker.

For high-risk systems, defenders should compare recent repository, pipeline, account, runner, and deployment activity against known-good records to identify potential follow-on abuse. Unexpected pipeline modifications, repository changes, newly issued tokens, or unusual access to build infrastructure should be investigated.

Given the CVSS 10.0 severity, confirmed exploitation, public reproduction, and rapid transition from disclosure to scanning, remediation should be treated as an emergency for internet-facing self-managed GitLab deployments.