Threat actors are exploiting a maximum-severity GitLab vulnerability disclosed last week, which could give adversaries an inside track into organizations' software supply chains.
CVE-2026-85706, which GitLab disclosed and patched on Sept. 10, is a path traversal flaw that allows unauthenticated individuals to read arbitrary files from the GitLab server. The vulnerability, which received a CVSS score of 10 out of 10, stems from improper path confinement and missing authentication checks in the platform's repository commits API, according to GitLab's advisory. The vulnerability exists in GitLab Community Edition (CE) and Enterprise Edition (EE), which organizations use to set up self-hosted GitLab instances within their environments.
The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on Sept. 11 and required federal agencies to patch or disable their self-managed GitLab instances by today. On the same day, researchers with cybersecurity vendor watchTowr observed behavioral probes for the flaw on its honeypot network.
And it's gotten worse since then.
GitLab Exploitation Jeopardizes Supply Chains
Jake Knott, head of threat intelligence at watchTowr, tells Dark Reading that malicious activity quickly escalated on Friday to full exploitation and the exfiltration of sensitive files.
"Over the weekend, we also observed threat actors dumping config files for secrets along with system SSH configurations for the victim system," Knott says. "The combination is, as you can imagine, potent, as it may allow threat actors the ability to extract passwords, connect to instances that allow password authentication, and gain access to the host under the right conditions."
Even though CVE-2026-85706 exploitation gives an attacker read-only access to a GitLab instance, the attacker could use that access to obtain sensitive information like credentials and CI/CD secrets; this could not only enable a full compromise of the GitLab instance but also grant the attacker further admission into an organization's development environment and other critical downstream systems. Knott describes the flaw as a supply chain attack-enabling vulnerability.
WatchTowr noted that CVE-2026-85706 is the second critical vulnerability in GitLab to be targeted recently. Last month, attackers exploited CVE-2026-19478, a GraphQL code injection flaw, shortly after it was publicly disclosed.
Mitigating CVE-2026-85706
On the bright side, Knott says exploitation of CVE-2026-85706 requires the targeted organization to have at least one public project on the GitLab server. On the not-so-bright side, he says, it's "probably a relatively common configuration," and some organizations might not be aware that they have public projects on the platform.
"Organizations running GitLab may gate access to the system, meaning projects would not be visible to an outsider without authentication, but that does not mean that projects that were created as 'public' are out of reach," Knott says. "In some cases, companies might want specific codebases to be exposed publicly. In others, they might falsely assume that the project is still 'internal' if it's made public within their GitLab system."
WatchTowr urged GitLab customers to update their self-hosted GitLab instances to versions 19.3.2, 19.2.6, or 19.1.8 for GitLab Community Edition and Enterprise Edition. If they cannot update, they should immediately remove all public access to their instances. GitLab Dedicated customers do not need to take action, according to GitLab. The online GitLab.com platform has already patched the flaw.
Additionally, watchTowr recommended that security teams review access logs on the repository commits API for any suspicious or unauthenticated requests that suggest probing or exploitation activity.