GitLab Path Traversal Flaw Expands Supply-Chain Risk Beyond File Reads

Exploitation moved quickly after disclosure

Early scanning and exploitation reports suggest defenders had little time between patch publication and attacker interest. Dark Reading reported that watchTowr observed behavioral probes for the flaw on September 11, the same day CISA added the issue to its KEV catalog.¹ Read Us 24x7 also reported that probing began within a day of GitLab’s September 10 patch release, with watchTowr honeypots seeing activity at 06:00 UTC on September 11.⁵

The vulnerability is rooted in improper path confinement and missing authentication enforcement in GitLab’s repository commits API, according to HKCERT and other security summaries.²⁶ In practical terms, attackers may be able to craft requests that escape expected repository paths and retrieve files elsewhere on the server, depending on instance conditions.

Researchers have also noted an important precondition: exploitation reportedly requires the target GitLab server to host at least one public project.¹⁵ That does not make the issue narrow. Many organizations intentionally expose some repositories, while others may not realize that a project marked public within a self-managed GitLab environment is reachable in ways that matter for this vulnerability.¹

Why file read can become supply-chain access

Although CVE-2026-85706 is described as an arbitrary file-read vulnerability, the impact can extend well beyond confidentiality. Source-code platforms often sit at the center of engineering trust. They store code, CI/CD configuration, deploy keys, package-publishing credentials, webhook tokens, runner registration data and integrations with cloud or identity systems.

Dark Reading reported that watchTowr saw activity escalate from probing to sensitive file exfiltration, including configuration files and SSH-related system data.¹ Hive Security advised defenders to rotate credentials that could have been read, including database, object-storage, SMTP, OAuth, webhook, integration, deploy, personal-access, project, group and runner credentials.³

That makes the principal risk a trust-boundary failure. If an attacker obtains secrets from a GitLab server, they may be able to access private repositories, modify pipelines, register or abuse runners, push malicious code, retrieve build artifacts, or reach deployment systems. Korean security reporting similarly warned that GitLab servers can contain proprietary source code, CI/CD configuration files, access tokens and deployment scripts, making them high-value targets for follow-on intrusion.⁴

What teams should do now

Administrators should first identify every self-managed GitLab CE or EE instance, including production, staging, standby and disaster-recovery systems. They should then upgrade to the fixed release for the relevant branch: 19.1.8, 19.2.6 or 19.3.2.²⁵ GitLab.com was reported as already patched, and GitLab Dedicated customers were reported as not needing action for this issue.¹³

If immediate patching is not possible, teams should remove public access or place the instance behind strict network controls as a temporary mitigation. They should not treat that as a substitute for applying the vendor fix.¹⁵

After patching, security teams should review GitLab, reverse-proxy, WAF and load-balancer logs for suspicious repository commits API activity. Hive Security recommended hunting for POST requests to repository commit API paths, especially requests containing file path parameters, traversal-like encodings, unauthenticated identities, unusual response sizes, or source addresses touching multiple projects or instances.³ CISO Korea’s report also cited guidance to inspect GitLab and reverse-proxy logs for unusual repository commits API requests and unexpected file-access patterns.⁴

Credential rotation should be scoped to what could have been accessed. Teams should prioritize tokens, SSH keys, database credentials, integration secrets, deploy keys, runner credentials and CI/CD variables that were readable by the GitLab server process. Hive Security cautioned against blindly regenerating GitLab secret material without following documented procedures, because mishandling encryption keys can make protected database values unreadable.³

No public breach count, but a shrinking response window

As of the September 14 reports, public sources had not identified a confirmed victim organization or published a reliable count of compromised GitLab instances.⁵ However, HKCERT classified CVE-2026-85706 as exploited in the wild, and P1-Critical summarized the issue as an actively exploited CVSS 10.0 flaw that can expose server files under certain conditions.²⁶

For DevSecOps teams, the lesson is familiar but urgent: source-code management systems are not ordinary web applications. When these systems are exposed, attackers are not only looking for files. They are looking for the credentials, automation paths and deployment privileges that can turn a single vulnerable development server into a software supply-chain foothold.