On September 10th, GitLab released a patch for versions 19.3.2, 19.2.6, and 19.1.8 of GitLab Community Edition (CE) and Enterprise Edition (EE) after the discovery of a critical flaw, tracked as CVE-2026-85706. Within hours, watchTowr saw probing related to this vulnerability in the wild. On September 11th, the United States Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its list of Known Exploit Vulnerabilities (KEVs). Binding Operational Directive (BOD) 26-04 requires federal remediation efforts to be prioritized based on risk, forcing the clock on remediation to start before many teams have even finished triage.
Critical Severity Path Traversal
The flaw is a path traversal vulnerability in GitLab’s repository commits API with a CVSS score of 10.0. A threat actor exploiting it could read arbitrary files from GitLab’s servers without authorization. This vulnerability requires no authentication and is low complexity and network-reachable, significantly lowering the barrier for exploitation in the wild.
The impacts of this vulnerability can cover a wide scope, including integrity, confidentiality, and availability of data. Potential consequences include the execution of unauthorized code or commands, reading and modification of files or directories, and denial-of-service (DoS) via crash, exit, or restart. Attackers can turn the ability to read files without authentication into control with stolen secrets like stored password files.
Git Servers’ Place in the Supply Chain
A vulnerability in GitLab inherently means there is risk to a wide range of systems through it. The first targets for attackers with the ability to read files without authorization are often gitlab.yml and secrets, containing application configuration data and highly sensitive data. Secrets can include CI/CD variables, runner tokens, and deploy keys that attackers can access by leveraging this flaw.
GitLab’s files and systems contain source code, pipelines, and production credentials, all in one place for attackers to read, modify, and possibly even destroy. Any damage done by attackers in these areas will be inherited downstream by customers. The widespread use of and reliance on GitLab makes this vulnerability an extreme risk for many organizations.
Challenges to Immediate Patching
Within the same patch bundle, GitLab also pushed fixes for another recently discovered critical vulnerability, tracked as CVE-2026-87719 with a CVSS score of 9.9. This flaw can enable an unauthenticated user with access to Duo Chat to obtain configurations and credentials by exploiting a GraphQL subscription argument and bypassing serialization.
The fixes for these vulnerabilities include database migrations, which force downtime for those running single-node instances. While GitLab’s software-as-a-service (SaaS) and Dedicated customers are already covered and do not need to act to fix the flaws, self-managed customers are left to their own devices to fit this patching into their operational schedules. “There are over 20,000 self-managed GitLab instances sitting on the public internet right now, and the only thing needed for exploitation is that a public project has to exist on the instance, which is extremely common,” says Denis Calderone, CTO, Suzu Labs.
The Patch Gap for Older Versions
The patch release covers flaws affecting every GitLab version after 18.7, but the initial fix only covered versions 19.3.2, 19.2.6, and 19.1.8. Backported patches for versions 19.0.9 and 18.11.12 were not released until September 23rd, almost two weeks later. Customers self-managing these older versions of GitLab were vulnerable to these flaws being exploited for far longer than those running newer versions.
This patch release schedule means that many customers are forced to make a choice between a major update to a newer version or staying exposed to attacks. This underlines the fact that effective upgrade discipline is not just an optional IT chore, but a critical security control.
Patching Does Not Guarantee Security
Thoroughly protecting against these and other exploitable vulnerabilities demands more than just patching GitLab to a fixed version. “Obviously, if you have a self-hosted GitLab instance, get it patched, but if your GitLab instance was exposed to the Internet before September 10, you need to assume someone already tried this and hunt for IOCs,” according to Calderone.
Alongside the patches for these vulnerabilities, GitLab has released three threat detections for self-managed customers to mitigate the dangers of local file inclusion (LFI) reading gitlab.yml, LFI via metadata.path parameter, and LFI file path attempt. These customers are also encouraged to hunt logs dating back to September 10th and even earlier to find possible exploits. If any unauthorized reads are located, it is vital to rotate all exposed secrets and tokens and audit all access to external services with exposed credentials after the read took place. Any instances of probing that can be found should be treated as potential incidents and handled accordingly.
Planning for the Next Vulnerability
Internet-facing developer platforms act as tier-one exposures that can open up access to a massive swath of other services, providing the first link in a chain that can have catastrophic consequences. Customers should make an effort to stay on current branches of GitLab and other platforms to avoid waiting for backported fixes to flaws like these. Pre-approved emergency change paths for KEV-class flaws can also help customers, especially those in critical sectors like government, patch these issues as soon as they are cataloged.
