A newly disclosed GitLab vulnerability has earned a perfect 10 severity rating and is already being exploited in the wild, according to a report published by CSO Online. CVE-2026-85706 allows attackers to read any file on vulnerable servers through a single HTTP request, with no authentication required. The path traversal bug affects self-managed Community Edition and Enterprise Edition instances and stems from inadequate security boundaries and missing authentication checks in GitLab's repository commits API.
The flaw impacts GitLab CE and EE versions 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The US Cybersecurity and Infrastructure Security Agency has placed CVE-2026-85706 on its Known Exploited Vulnerabilities catalog, and watchTowr Intel reports it's observing in-the-wild probes. This marks the second major GitLab flaw in just one month. GitLab's platform serves roughly 50% of Fortune 100 companies and counts more than 50 million estimated registered users. Defenders can identify exploitation attempts by searching log files for HTTP POST requests to "/api/v4/projects/{id}/repository/commits/" URIs that contain "file.path" parameters.
"GitLab is not simply a source-code repository," Safayat Moahamad of Info-Tech Research Group noted in the report. In most enterprises, it's wired into build pipelines, deployment processes, application security workflows, and other trusted systems. Consequently, unauthorized access to configuration files, secrets, or credentials on the GitLab server could "create consequences well beyond the affected instance," according to Moahamad. This isn't a bug that companies should postpone for their regular patch schedule, he stressed. "It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows."
The vulnerability's danger stems from GitLab's role as critical trust infrastructure that often connects to sensitive repositories, CI/CD pipelines, cloud environments, and production deployment processes. The data and access attackers could obtain depends on what the GitLab service can read and what organizations store on the server, including configuration files, secrets, credentials, and other sensitive server-side information. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure. David Shipley of Beauceron Security described two factors colliding to generate "maximum pain" for GitLab users: the perfect-10 vulnerability combined with developers' persistent bad habits of shipping code with embedded SSH keys, cloud secrets, tokens, and other valuable data. "This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number," Shipley said. "It opens up a world of criminal data shopping."
GitLab has fixed the vulnerability and urged customers with public-facing self-hosted instances to patch their servers immediately or remove public access. Enterprises should patch without delay, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, Moahamad advised. WatchTowr Intel warned that "based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away." Resilience will depend on 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. "Get those secrets out of production code and adopt modern coding authentication best practices," Shipley advised. Organizations treating CI/CD infrastructure as anything less than mission-critical are learning that lesson the expensive way. When your entire software supply chain runs through a single platform, a single unauthenticated endpoint becomes an existential threat.