Hackers Are Probing a Critical GitLab Flaw. Here’s What Businesses Need to Do Now

A critical GitLab vulnerability is now being exploited against internet-facing systems, turning an already urgent patching notice into an incident-response problem for businesses that run their own GitLab servers.

The flaw, tracked as CVE-2026-85706, affects the repository commits API in GitLab Community Edition and Enterprise Edition. Under certain conditions, an unauthenticated attacker can use path traversal to read arbitrary files from the server. GitLab assigned the vulnerability a CVSS score of 10.0, the highest possible rating.

GitLab released fixes on September 10 in versions 19.1.8, 19.2.6 and 19.3.2. The affected ranges include versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The issue is primarily a concern for self-managed installations exposed to the internet; GitLab’s hosted services run infrastructure controlled by the company.

The speed of the response matters. WatchTowr, a security firm that monitors exposed systems and honeypots, reported seeing probes for the vulnerability beginning at 06:00 UTC on September 11—within roughly a day of public disclosure. The U.S. Cybersecurity and Infrastructure Security Agency subsequently added the flaw to its Known Exploited Vulnerabilities catalog, confirming that the issue is being used in real-world attacks rather than merely discussed as a theoretical risk.

The vulnerability does not need to start with a stolen GitLab password. That is what makes it particularly dangerous. If an exposed installation meets the conditions for exploitation, an attacker may be able to retrieve server-side files without first authenticating. Depending on the system’s configuration, those files could reveal CI/CD variables, deployment credentials, application secrets, configuration data or information useful for accessing the underlying host.

For developers, the risk extends beyond the GitLab instance itself. GitLab frequently sits at the center of a software delivery chain: repositories connect to runners, build systems, cloud accounts, package registries and production environments. A stolen token may therefore give an attacker a path to tamper with builds, access private code or reach systems that are not directly exposed to the internet.

The immediate priority is to upgrade. Teams should not wait for a normal maintenance window if their self-managed instance was running an affected version. After patching, administrators should review reverse-proxy, web-server and GitLab logs for suspicious POST requests to the repository commits endpoint, especially requests containing file-path parameters.

Patching alone may not be enough. If the server was reachable from the internet while vulnerable, organizations should assume that sensitive credentials may have been exposed until they can establish otherwise. That means rotating CI/CD variables, deploy tokens, runner registration tokens, personal access tokens, database credentials, cloud credentials and SSH keys where appropriate. Security teams should then search for use of those credentials and review recent pipeline, repository and administrative activity.

There is an important distinction between what is known and what is not. Security researchers have observed exploitation activity and reported the extraction of sensitive files. That does not establish that every vulnerable server was compromised, nor does it identify a particular attacker or prove that a specific company suffered a breach. But for defenders, the uncertainty cuts in one direction: an exposed system should be investigated as potentially compromised, not treated as safe merely because no obvious code changes are visible.

The same GitLab patch releases addressed another critical Enterprise Edition vulnerability, CVE-2026-87719, along with additional high-severity flaws. That makes the update more than a single-CVE fix. For organizations operating GitLab as part of their build and deployment infrastructure, the lesson is broader: code-hosting platforms are security control points, and a vulnerability that begins as a read-only bug can become a supply-chain problem when it exposes the credentials that automate production.