The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a critical GitLab vulnerability to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation.
Tracked as CVE-2026-85706, the path traversal flaw carries a CVSS score of 10.0 and affects self-managed GitLab Community Edition and Enterprise Edition installations. Under certain conditions, it can allow an unauthenticated attacker to read arbitrary files from a vulnerable server.
The vulnerability exists in GitLab’s repository commits API. GitLab said improper path confinement and missing authentication enforcement could allow attackers to access files outside the intended repository location.
GitLab released patched versions 19.1.8, 19.2.6 and 19.3.2 on Sept. 10. Affected releases include versions from 18.7 through versions earlier than 19.1.8, version 19.2 through versions earlier than 19.2.6, and version 19.3 through versions earlier than 19.3.2. GitLab.com was already patched, while GitLab Dedicated customers do not need to take action.
On Sept. 11, watchTowr reported seeing behavioral probes for the vulnerability across its honeypot network. CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day and set a Sept. 14 remediation deadline for affected Federal Civilian Executive Branch agencies.
The risk extends beyond exposed files: GitLab servers can contain credentials, tokens and configuration data connected to development pipelines, potentially giving attackers a path into build, cloud or deployment systems.
How exposed GitLab files could compromise development pipelines
The immediate capability is read access, but the files sitting on a GitLab server can determine how far an intrusion goes.
GitLab is deeply embedded in software development and CI/CD environments. Configuration files, credentials, SSH keys, deployment tokens and other secrets can potentially provide access to systems connected to the development pipeline.
Jake Knott, head of threat intelligence at watchTowr, told Dark Reading that researchers observed attackers dumping configuration files containing secrets and system SSH configurations. That makes the vulnerability more than a problem confined to a GitLab server. Exposed credentials could potentially become a route into cloud infrastructure, build systems or deployment environments.
What organizations should do now?
Organizations running public-facing, self-managed GitLab should upgrade immediately or remove public access until they can patch, security experts said. WatchTowr recommends checking logs for HTTP POST requests targeting /api/v4/projects/{id}/repository/commits/ that contain file.path parameters.
Because exploitation may have occurred before an update was installed, organizations should not treat patching as the end of the response. Administrators should determine which files were accessible, investigate for signs of compromise, and rotate credentials, deployment tokens, SSH keys or other secrets that may have been exposed.
CVE-2026-85706 shows how arbitrary file access can create broader supply chain risk when the affected server is connected to development and deployment systems. Organizations should patch immediately, but they should also investigate whether exposed GitLab data provided access to other parts of their environment.