GitLab's Perfect 10 Flaw Exposes Secrets

A maximum-severity vulnerability in GitLab's repository commits API allows an unauthenticated attacker to read arbitrary files from a vulnerable server in a single HTTP request. The flaw, tracked as CVE-2026-85706, carries a severity score of 10 and affects both GitLab Community Edition and Enterprise Edition. It is the second flaw GitLab has disclosed in roughly a month.

How the path traversal works

According to GitLab, the vulnerability stems from improper confinement and a lack of authentication enforcement in the repository commits API. That combination produces a path traversal issue: an attacker can craft a request that escapes the intended directory boundary and returns files that should never be reachable without credentials. GitLab said the flaw can be exploited under certain conditions to read arbitrary files, including credentials, secrets, and other sensitive data stored on the server.

The affected versions are GitLab CE and EE 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The company has released fixes and is directing customers with public-facing self-hosted instances to patch immediately or remove public access. The bug was reported through GitLab's HackerOne bug bounty program.

Because the attack requires only a single HTTP request and no authentication, it sits in a class of flaws that defenders have learned to treat as urgent. There is no need for valid user credentials, no need for a compromised account, and no need for the attacker to interact with a browser session. If the server is reachable, the request can be sent.

Why GitLab is a high-value target

GitLab's DevSecOps platform is used by roughly 50% of the Fortune 100, and the company has more than 50 million estimated registered users. Those figures help explain why a flaw in the platform draws attention well beyond the organizations that run it directly.

The deeper issue is what GitLab represents inside an enterprise. It is rarely just a place where source code sits. In many environments it connects to build pipelines, deployment processes, application security workflows, and other trusted systems. A repository server that can read its own configuration files and secrets is therefore not an isolated asset.

Attackers who gain unauthorized read access to configuration files, secrets, or credentials on the GitLab server can create consequences well beyond the affected instance, according to Safayat Moahamad, advisory director at Info-Tech Research Group.

Patch immediately, and then check your logs

Moahamad's guidance is blunt: this is not a vulnerability that organizations should leave for the normal patch cycle. "It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows," he said.

For defenders who need to determine whether they have already been hit, the watchTowr Intel team has published a concrete hunting approach. It advises looking through log files for HTTP POST requests to "/api/v4/projects/{id}/repository/commits/" URIs containing "file.path" parameters.

Detection matters because the exploitation window may be short. CISA has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, noting that this type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. WatchTowr Intel has reported it is already observing in-the-wild probes. "Based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away," it warned.

What attackers can actually reach

The information or access an attacker can obtain depends on what the GitLab service can read and what an organization stores on the server. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure.

Moahamad described the flaw as directly creating an unauthorized file access risk. Possible follow-on scenarios he listed include credential theft, lateral movement, source code exposure, and supply chain compromise. Each of those depends on what the initial read returns, but the path from a single unauthenticated request to a broader compromise is not theoretical in environments where secrets live alongside code.

The organizations most exposed are those running affected self-managed GitLab CE or EE instances. The risk climbs further where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes.

Two factors colliding

David Shipley of Beauceron Security described two factors colliding to generate what he called maximum pain for GitLab users. The first is the vulnerability itself. "It's a 10 for a reason: Unauthenticated read access to GitLab client source code," he said.

The second factor is developer habit. Too much code continues to ship, or sits in production, with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said. When a flaw opens a read path into a repository server, the value of what is stored there is what determines the damage.

Shipley listed the criminal playbook that follows from that combination: data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the theft of AI tokens and infrastructure to enable other criminal activity. "This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number," he said. "It opens up a world of criminal data shopping."

Treat source code platforms as trust infrastructure

Moahamad argued that source code and CI/CD platforms need to be governed as critical trust infrastructure. Patching remains essential, but he said resilience depends on several other things: knowing where platforms can be exposed, limiting what they can access, detecting abnormal API behavior, and having a tested process for investigating and rotating credentials.

That last point is where many incident responses stall. A file read that exposes credentials does not end when the server is patched. It ends when the organization has determined whether exposed files contained credentials or secrets that may now require rotation. Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate that question directly, Moahamad advised.

Shipley's bottom line is similarly direct: "Get those secrets out of production code and adopt modern coding authentication best practices," he advised.

Previous GitLab fixes this year

GitLab has been a recurring target. In January, the company patched a high-severity flaw that allowed attackers possessing a target's account ID to bypass two-factor authentication. In August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even delete them with a single HTTP request.

The current bug adds arbitrary file read to that list. Taken together, the pattern is one of unauthenticated access paths into a platform that many organizations treat as internal and trusted. The fixes exist, but the exposure window is defined by how quickly each instance is updated.

What this means for defenders

The immediate action is straightforward for anyone running an affected self-managed GitLab instance: patch to a fixed release, or take the server off public access. That is GitLab's own guidance, and CISA's addition of the vulnerability to its Known Exploited Vulnerabilities catalog makes the case for treating it as urgent rather than routine.

The harder work comes after the patch. This flaw could mean that credentials, tokens, or keys stored on a GitLab server were readable by anyone who knew the right request to send. Organizations that delay checking their logs may never know whether a probe succeeded, and credentials that were exposed remain usable until they are rotated. The value of a CI/CD platform is that it touches so much of how software gets built and shipped; the same connectivity that makes it useful is what makes a read path into it costly.

For teams that treat source control and pipelines as plumbing rather than security-critical infrastructure, this bug is a reminder that the distinction does not hold up. The server that holds the code is also the server that holds the keys to deploy it.