GitLab CVE-2026-85706: Path Traversal in the Commits API Allows Unauthenticated Reading of Arbitrary Files — Actively Exploited, CVSS 10.0, Now in the CISA KEV
GitLab published CVE-2026-85706 on 10 September 2026: a path traversal vulnerability (CWE-22) in the commits API of self-managed installations. The flaw combines insufficient path confinement with missing authentication enforcement at the endpoint /api/v4/projects/{id}/repository/commits/. A single unauthenticated request reads arbitrary files from the server. CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). watchTowr and Rapid7 confirm active exploitation since 11 September 2026, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on 15 September 2026. Affected are GitLab CE and EE from 18.7 through 19.3.1, fixed in 19.1.8, 19.2.6 and 19.3.2. GitLab.com and GitLab Dedicated are not affected.
TL;DR — 90 seconds
A path traversal flaw in the GitLab commits API lets unauthenticated attackers read arbitrary files from the server. CVSS 10.0, the maximum score on the scale. Active exploitation has been confirmed since 11 September 2026, and CISA added the flaw to its KEV catalog four days later. Only self-managed instances (Omnibus, source, Helm chart) running 18.7 through 19.3.1 are affected. The fix ships in 19.1.8, 19.2.6 and 19.3.2. If you cannot patch immediately, take the instance off the public network.
What is the problem?
The vulnerable endpoint sits in the commits API at /api/v4/projects/{id}/repository/commits/. A file-path parameter is not sufficiently checked against directory traversal sequences. Combined with missing authentication enforcement at this endpoint, an attacker without credentials can read arbitrary files from the GitLab server's filesystem, including configuration files, secrets, or private SSH keys.
The vulnerability affects only self-managed installations. GitLab.com and GitLab Dedicated are operated by GitLab itself and are hardened separately; no action is needed there.
Who is affected?
All self-managed deployments of GitLab CE and EE in the following version ranges:
| Version range | Status | Fix version |
|---|---|---|
| 18.7 – 19.1.7 | Affected | 19.1.8 |
| 19.2.0 – 19.2.5 | Affected | 19.2.6 |
| 19.3.0 – 19.3.1 | Affected | 19.3.2 |
| GitLab.com / GitLab Dedicated | Not affected | — |
What matters is the installation type, not company size. Every self-hosted instance in the affected version ranges is vulnerable, whether it is publicly reachable or only reachable internally.
Impact
A successful attack reads files with the privileges of the GitLab process. That is typically enough to reach gitlab-secrets.json, database configuration files, or private SSH keys in the GitLab user's home directory. A pure file-read primitive commonly becomes a stepping stone to full instance compromise: secrets allow forging sessions, and SSH keys allow repository access and CI/CD pipeline manipulation.
Because CI/CD pipelines frequently carry production deploy credentials, the chain often reaches into the production environment in many setups. An unauthenticated read turns into a potential full supply-chain compromise.
Mitigation / Immediate actions
Patch immediately, outside your regular maintenance window. Update your self-managed instance through the path appropriate for your installation type (Omnibus package manager, source update script, or Helm chart upgrade) to 19.1.8, 19.2.6, or 19.3.2, depending on your current minor version. The update includes database migrations; expect brief downtime on single-node systems during the migration, and plan for it.
If immediate patching is not possible, take the instance off the public network, or restrict access to the commits API through an upstream firewall or reverse proxy to known IP ranges. This is explicitly a stopgap only; no publicly documented WAF pattern for this flaw currently exists.
Detection / Verification
Review GitLab access logs (production_json.log or your upstream reverse proxy) for POST requests against /api/v4/projects/{id}/repository/commits/ containing a file-path parameter with traversal sequences (../) or absolute paths outside the repository directory.
Also check whether, since 10 September 2026, unexpected access to sensitive paths such as /etc/gitlab/gitlab-secrets.json or .ssh/ directories shows up in the logs. CISA and several security vendors report active scanning on the internet; a hit in the logs should be treated as an indicator of compromise, not merely a failed attempt.
Operator recommendation
Act today if: your GitLab self-managed instance is reachable from the internet and runs a version between 18.7 and 19.3.1. Patch today, or take the instance off the network.
Monitoring is enough if: your instance already runs 19.1.8, 19.2.6, 19.3.2 or newer, or you use only GitLab.com or GitLab Dedicated.
Either way, review last week's access logs for suspicious commits-API calls, regardless of your current patch level.
Frequently asked questions about CVE-2026-85706
Is GitLab.com affected by CVE-2026-85706?+
No. Only self-managed installations (Omnibus, source, Helm chart) are affected. GitLab.com and GitLab Dedicated are operated by GitLab itself and are not vulnerable.
Is a firewall rule enough, or do I need to patch?+
Removing access from the public network is only a stopgap. The only reliable fix is updating to 19.1.8, 19.2.6, or 19.3.2.
What access does an attacker get after a successful read?+
The attacker reads files with the privileges of the GitLab server process, not direct shell access, but often enough to escalate further via secrets or SSH keys.
Does the update cause downtime?+
Yes, potentially. The update includes database migrations; expect brief downtime during the migration on single-node systems. Plan a maintenance window even if you are patching outside your normal schedule.
Is there public exploit code?+
No detailed public exploit has been confirmed. watchTowr and Rapid7 confirm they reproduced the flaw themselves, and several vendors report active scanning on the internet.
How does this differ from earlier GitLab path traversal flaws?+
Earlier flaws usually required an authenticated account or affected only specific file types. CVE-2026-85706 is unauthenticated and allows arbitrary files, hence the maximum CVSS score of 10.0.
Conclusion
CVE-2026-85706 shows once again how quickly a single unauthenticated read primitive turns into a full compromise when secrets and SSH keys sit next to the application. The maximum CVSS score and confirmed active exploitation make immediate patching the only reliable response; access restriction is only a stopgap until the update lands.
Sources
I review your GitLab self-managed instances for patch status, harden network and access logic around CI/CD systems, and support incident analysis after possible exploitation.
Patch audits, log review for compromise indicators, hardening of reverse-proxy and network access for GitLab self-managed and adjacent CI/CD components.
Ongoing platform operations, not paper advice: I review, patch, and harden your infrastructure continuously.