GitLab Patches CVSS 10.0 Path Traversal Vulnerability Amid Active Exploitation of Commits API

At 06:00 UTC on September 11, 2026, security honeypots operated by threat intelligence firm watchTowr began recording automated HTTP POST requests directed at a specific GitLab API endpoint. The incoming traffic was not attempting to log in or guess passwords; instead, the probes were testing a newly disclosed method to extract configuration files and SSH keys directly from the server's underlying file system.[3][6]

The activity followed GitLab's emergency release of patches on September 10 for CVE-2026-85706, a maximum-severity vulnerability carrying a CVSS score of 10.0. The flaw allows an unauthenticated remote attacker to read arbitrary files from any self-managed GitLab Community Edition (CE) or Enterprise Edition (EE) server that hosts at least one public project.[2][4]

The vulnerability resides in the repository commits API, specifically the `/api/v4/projects/{id}/repository/commits` endpoint. According to GitLab's security advisory, the root cause is a combination of improper path confinement and a failure to enforce authentication checks on the affected file-handling functionality.[1][5]

In a secure configuration, this API endpoint should only return files located within the intended repository directory. However, by supplying a specially crafted `file.path` parameter containing directory traversal sequences, an attacker can force the application to escape the repository root and reference other files readable by the GitLab service process.[5][6]

Because the endpoint lacked authentication enforcement, anyone on the internet could send the crafted request. Jake Knott, head of threat intelligence at watchTowr, noted the speed of the weaponization, stating, "This is the second instance of a critical severity GitLab vulnerability in recent weeks," and confirming that attackers had successfully reverse-engineered the weakness within hours of the patch release.[2]

The exposure is particularly severe because of GitLab's role in the software development lifecycle. Self-managed instances typically store continuous integration variables, database credentials, deployment tokens, and proprietary source code. Extracting these secrets provides adversaries with the necessary materials to compromise downstream production environments and software supply chains.[3][6]

Recognizing the immediate risk, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on September 11. Under Binding Operational Directive 26-04, CISA mandated that all Federal Civilian Executive Branch agencies apply the vendor-supplied fixes by September 14.[2][5]

GitLab has resolved the issue in versions 19.3.2, 19.2.6, and 19.1.8, affecting deployments from version 18.7 onward. The company confirmed that its cloud-hosted GitLab.com and GitLab Dedicated environments were already protected against the exploit, leaving the risk concentrated entirely on internet-facing, self-managed deployments.[1][5]

Security teams defending self-hosted instances must upgrade immediately and review their web server telemetry. Defenders can identify potential exploitation attempts by scanning reverse-proxy and web application firewall logs for HTTP POST requests to the commits API that contain unusual path traversal sequences attempting to leave the expected directories.[1][6]