Critical GitLab Flaw Allows Attackers to Steal Files Without Login

A severe vulnerability in GitLab's repository commits API is exposing self-managed instances to unauthenticated attackers capable of reading arbitrary files directly from affected servers. CVE-2026-85706 has earned a maximum severity rating of 10.0 and is already being exploited in the wild.

What's at Risk#

The flaw impacts GitLab Community Edition and Enterprise Edition versions 18.7–19.3.1. Because the API endpoint fails to properly validate file paths and enforce authentication checks, an attacker with no credentials can traverse the server's filesystem and extract sensitive materials. The only precondition: at least one public project must exist on the instance.

Researchers note that CI/CD variables, runner tokens, SSH keys, and deployment credentials are prime targets. Once obtained, these artifacts could allow attackers to:

• Compromise build pipelines
• Pivot into connected systems that GitLab can access
• Pull malicious packages or container images into the organization's supply chain

Timeline and Disclosure#

Security researcher Mohamed Abdelaiz disclosed the vulnerability on September 11, and GitLab released patches immediately. Within hours, in-the-wild scanning began, prompting the U.S. Cybersecurity and Infrastructure Security Agency to add the flaw to its Known Exploited Vulnerabilities Catalog.

Beyond Patching#

Deploying the latest versions—19.3.2, 19.2.6, 19.1.8, or later—is essential, but security experts caution it's only part of the response. The fix blocks new file reads but does not undo exposure of credentials already stolen. Organizations must:

• Rotate all CI/CD variables, deploy tokens, and SSH keys that were active during the vulnerability window
• Audit build logs and package registries to spot any suspicious dependencies or images pulled while old credentials were in use
• Search server logs for suspicious POST requests to /api/v4/projects/{id}/repository/commits/ endpoints containing parameters