TL;DR — CVE-2026-85706 is a CVSS 10.0 (Critical) path-traversal flaw in GitLab CE/EE that lets a completely unauthenticated attacker read arbitrary files from a self-managed GitLab server — logs, configuration, and the secrets and tokens inside them — simply by abusing the repository commits API. GitLab shipped fixes on 10 September 2026; within roughly a day, watchTowr saw in-the-wild probing, and CISA added the bug to its Known Exploited Vulnerabilities catalog on 11 September 2026 with a three-day federal patch deadline of 14 September. The only precondition is that the instance hosts at least one public project. If you run self-managed GitLab exposed to the internet, treat this as an emergency: patch, then rotate every secret it could have leaked.
What Is the GitLab Commits-API Path Traversal (CVE-2026-85706)?
GitLab is one of the most widely deployed DevOps platforms in the world, and its self-managed Community and Enterprise editions sit at the centre of countless software supply chains — holding source code, CI/CD pipelines, deploy keys and the credentials that glue an organisation’s build and release process together. CVE-2026-85706 is a path-traversal vulnerability in the repository commits API that lets an unauthenticated attacker step outside the intended repository directory and read arbitrary files from the underlying server.
GitLab rates the flaw CVSS 3.1 10.0 (Critical) — the maximum possible score — and classifies it as a path-traversal weakness (CWE-22, improper limitation of a pathname to a restricted directory). The vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, explains why it tops out: the attack is over the network, needs no privileges and no user interaction, and crosses a scope boundary — a flaw in the web application reaches files owned by the host that sit entirely outside GitLab’s intended remit. The one catch, as GitLab and researchers have noted, is refreshingly small for an attacker: the target instance need only host at least one public project.
How the CVE-2026-85706 Exploit Works
In plain terms: GitLab’s commits API is meant to hand back information about files inside a repository. This bug lets an attacker put a booby-trapped file path into that request — one that climbs out of the repo folder using directory-traversal sequences — and GitLab dutifully reads whatever the path points at, even system files that have nothing to do with the repository. Because the endpoint does not demand a login, the attacker never has to be a user of the platform at all.
Technically, the root cause is improper path confinement combined with missing authentication enforcement (CWE-22) in the repository commits API. The vulnerable route accepts a file.Path value that is not properly canonicalised or constrained to the repository’s working tree. By supplying traversal sequences in that parameter against a /api/v4/projects/{id}/repository/commits/ request, an attacker redirects the file lookup to an arbitrary location on disk. GitLab then returns the contents, giving the attacker a reliable arbitrary-file-read primitive. There is no memory corruption and no exploit chain to stabilise — it is a clean logic flaw, which is precisely what makes it so easy to weaponise and so attractive for mass scanning.
What that primitive yields is the real danger. Security researchers observed attackers pulling GitLab log files and configuration files (the kind that hold database credentials, the Rails secret_key_base, SMTP passwords and integration tokens) as well as system SSH configurations — turning a “read-only” bug into a springboard for full compromise and lateral movement.
Impact Nuance: “Just” a File Read That Owns the Server
It is worth being precise about what this vulnerability is and is not. On paper, CVE-2026-85706 is an arbitrary file read, not remote code execution — the confidentiality impact is High while integrity and availability are marked None in the vector (C:H/I:H/A:N reflects GitLab’s scope-crossing scoring rather than direct code execution). An attacker cannot, through this bug alone, drop a web shell or run commands.
That distinction offers little comfort in practice. A self-managed GitLab server is a secrets vault: its configuration and logs routinely expose CI/CD tokens, deploy keys, database and object-storage credentials, and the application secret that can be used to forge sessions. Reading those files is frequently equivalent to owning not just GitLab but the pipelines and downstream systems it controls — a textbook supply-chain exposure. That is why GitLab scored it a perfect 10.0 despite it being “only” a read: when the files you can read are the keys to everything else, the boundary between information disclosure and total compromise all but disappears.
An unauthenticated file read sounds modest until you remember what lives on a GitLab box: the tokens, deploy keys and secrets that unlock the entire pipeline. Patch the read, then rotate everything it could have touched.
Active Exploitation of CVE-2026-85706
This is confirmed, fast-moving in-the-wild exploitation. According to the exposure-management firm watchTowr, opportunistic in-the-wild probing began around 06:00 UTC on 11 September 2026 — within roughly a day of GitLab publishing the patch on 10 September. Reporting by The Hacker News and others described the activity escalating over the following days from behavioural probing to successful exploitation and exfiltration, with attackers observed dumping configuration files for secrets along with system SSH configurations. Hong Kong’s CERT independently confirmed exploitation on 14 September 2026.
CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities (KEV) catalog on 11 September 2026, setting an unusually short remediation deadline of 14 September 2026 for US federal civilian agencies — a three-day window that signals how seriously the exploitation is being taken. A public IOC scanner and detection toolkit (with Sigma, Suricata/Snort and SIEM rules) has been published on GitHub, and the trivial nature of the flaw means defenders should assume that mass, indiscriminate exploitation is already underway rather than imminent. If your instance was internet-exposed and unpatched at any point after 10 September, assume it was probed.
Remediation & Mitigation: Patching the GitLab File-Read Flaw
Upgrade self-managed GitLab now. This is an actively exploited CVSS 10.0 bug with a fix already available and a CISA deadline that has passed — it belongs at the very top of your queue. Upgrade to a patched release or later:
- GitLab CE/EE 19.3.x — upgrade to 19.3.2 or later.
- GitLab CE/EE 19.2.x — upgrade to 19.2.6 or later.
- GitLab CE/EE 18.7 through 19.1.x — upgrade to 19.1.8 or later.
GitLab.com (the SaaS platform) was patched by GitLab and requires no customer action; this advisory is about self-managed installations. Verify your running version under Admin → Help or with gitlab-rake gitlab:env:info, and confirm you are on a fixed build before considering the incident closed.
If you cannot patch a host immediately:
- Take the instance off the public internet. Restrict access to the GitLab web/API endpoints to a VPN or trusted IP ranges until you can upgrade — unauthenticated, internet-facing instances are the ones being hit.
- Watch the commits API. Alert on requests to
/api/v4/projects/{id}/repository/commits/that carryfile.Pathparameters containing traversal sequences (../, encoded variants) or absolute paths, and on unauthenticated 200 responses to that route. - Deploy the community IOC rules. Public Sigma and Suricata/Snort signatures for this CVE can flag exploitation attempts in the interim.
After patching, assume the secrets are burned. Because a successful read leaks whatever the GitLab service can see, treat any instance that was exposed and unpatched as compromised and rotate everything the server held: the Rails secret_key_base and other values in gitlab-secrets.json, database and Redis credentials, object-storage keys, SMTP passwords, CI/CD variables, personal and project access tokens, deploy keys and any SSH keys referenced in system configuration. Then hunt: review access logs for anomalous commits-API traffic since 10 September, check for unexpected sessions or new tokens, and audit downstream systems those secrets could reach.
Related ZeroDayHub Coverage
Developer and CI/CD platforms have become prime targets precisely because they concentrate so much access in one place. We covered a different GitLab flaw earlier this month in our write-up of the GitLab GraphQL code-injection exploited in the wild (CVE-2026-19478), and the same “read the secrets, own the pipeline” pattern in the JFrog Artifactory authentication bypass (CVE-2026-82329). Both underline the lesson of CVE-2026-85706: on a build server, an information-disclosure bug is rarely “just” information disclosure.
Sources & Further Reading
- GitLab — Critical Patch Release 19.3.2, 19.2.6, 19.1.8 (CVE-2026-85706 CVSS 10.0 / vector, affected & fixed versions)
- The Hacker News — GitLab CVSS 10 file-read flaw draws in-the-wild probes after disclosure
- Cyber Security News — CISA warns of GitLab path-traversal vulnerability exploited in attacks
- NVD — CVE-2026-85706 detail record
- CISA — Known Exploited Vulnerabilities Catalog
- Community IOC scanner & detection toolkit for CVE-2026-85706 (Sigma / Suricata / Snort)
ZeroDayHub reports on vulnerabilities for defensive purposes only. This article deliberately omits working exploit code and traversal payloads while patching is in progress.
Leave a Reply