A maximum severity GitLab flaw could turn your CI/CD server into an attacker’s treasure trove

Yet another security vulnerability has been discovered in GitLab infrastructure, this one a perfect 10 in severity. CVE-2026-85706, the second flaw GitLab has disclosed in just a month, is a maximum-severity vulnerability that allows attackers to read arbitrary files in a single HTTP request. The path traversal flaw results from improper confinement and lack of authentication enforcement in GitLab’s repository commits API, the company reported. Threat actors could exploit it “under certain conditions” and read arbitrary files (credentials, secrets, and other sensitive data) on vulnerable GitLab servers. The company has fixed the vulnerability, which impacts GitLab Community Edition (CE) and Enterprise Edition (EE), and has advised customers with public-facing self-hosted GitLab instances to patch their servers immediately, or remove public access. Experts say the flaw is alarming because GitLab’s DevSecOps platform is used by roughly 50% of the Fortune 100 and has more than 50 million estimated registered users. “GitLab is not simply a source-code repository,” noted Safayat Moahamad, advisory director at Info-Tech Research Group. In many enterprises, it is connected to build pipelines, deployment processes, application security workflows, and other trusted systems. As a result, unauthorized access to configuration files, secrets, or credentials on the GitLab server could “create consequences well beyond the affected instance,” he said. Don’t wait for the normal patch cycle GitLab has been a favorite hacker target of late: In January, it patched a high-severity flaw that allowed attackers possessing a target’s account ID to bypass two-factor authentication, and in August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even completely delete them with a single HTTP request. The current maximum severity bug, CVE-2026-85706, was reported through GitLab’s HackerOne bug bounty program. It affected 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 (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 particularly poses significant risks to the federal enterprise; watchTowr Intel has reported that 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. This is not a vulnerability that organizations should leave for the normal patch cycle, Moahamad emphasized. “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. Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, he advised. Beyond patching, the watchTowr Intel team said defenders should try to identify exploitation attempts by hunting through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters. CI/CD platforms are critical trust infrastructure  Organizations running affected self-managed GitLab CE or EE instances should be most concerned, Moahamad noted. Risk increases where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes. The information and/or access that attackers could obtain depends on what the GitLab service can read and what organizations store on the server, he explained. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure “The flaw directly creates an unauthorized file access risk,” he said. Credential theft, lateral movement, source code exposure, and supply chain compromise are possible follow-on scenarios. Source code and CI/CD platforms must be governed as “critical trust infrastructure,” he said. While patching remains essential, 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. David Shipley of Beauceron Security described two factors colliding to generate “maximum pain” for GitLab users. First is the vulnerability. “It’s a 10 for a reason: Unauthenticated read access to GitLab client source code,” he said. Second, this especially hurts because developers still have bad habits: way too much code continues to ship or is in production with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said. “So for attackers, you’ve got the classics,” he noted: Data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the stealing 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,” Shipley said. “It opens up a world of criminal data shopping.” The bottom line: “Get those secrets out of production code and adopt modern coding authentication best practices,” he advised.