GitLab Repository Commits API Path Traversal Vulnerability (Actively Exploited)

Summary

An unauthenticated path traversal vulnerability in the GitLab repository commits API allows a remote attacker to read arbitrary files from a self-managed GitLab server. A single HTTP POST request to /api/v4/projects/{id}/repository/commits/ with a crafted file.path parameter is sufficient to read any file accessible to the GitLab service account. The only precondition is that the target instance hosts at least one public project — a condition satisfied by almost every institutional deployment.

GitLab released patched builds on 10 September 2026 as part of a broader batch of 17 vulnerability fixes. In-the-wild probes were detected from 11 September 06:00 UTC — within hours of the public patch, indicating attackers reverse-engineered the vulnerability from the fix diff. CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog the same day with a federal remediation deadline of 14 September 2026.

Impact

Exploitability signals: CVSS 10.0 (maximum) · active in-the-wild exploitation confirmed by watchTowr honeypot data and CISA · unauthenticated, single-request exploit · scope-changed · fix diff reverse-engineered within hours of the 10 September release.

Successful exploitation reads any file readable by the GitLab service account. On a typical self-managed deployment that includes:

• /etc/gitlab/gitlab.rb and gitlab-secrets.json — Rails secret key base, database credentials, LDAP bind credentials, SMTP credentials, OAuth application secrets, and CI/CD variable encryption keys
• Files containing GitLab Runner registration tokens
• Application and Sidekiq logs, which frequently contain request contents including tokens
• Uploaded repository artefacts and cached data

The credentials recoverable from these files typically extend well beyond GitLab itself into directory services, mail infrastructure, CI/CD pipelines, and downstream systems that trust GitLab-signed tokens. Treat this as a credential-disclosure event, not merely a file-read event.

GitLab.com (SaaS) is already patched and is not affected by this advisory. This applies to self-managed Community Edition and Enterprise Edition deployments.

Affected systems

GitLab Community Edition and Enterprise Edition, self-managed, running:

• 18.7 through 19.1.7 — fixed in 19.1.8
• 19.2 through 19.2.5 — fixed in 19.2.6
• 19.3 through 19.3.1 — fixed in 19.3.2

The 10 September patch release also addresses two other criticals worth applying in the same maintenance window: CVE-2026-87719 (CVSS 9.9, GraphQL deserialization exposing credentials via Duo Chat) and CVE-2026-88765 (CVSS 8.5, Unicode-handling buffer overflow enabling RCE from a crafted Git repository). Both are fixed by the same upgrade.

Action

1. Upgrade immediately to 19.1.8, 19.2.6, or 19.3.2 on your version train. The same upgrade also closes CVE-2026-87719 (CVSS 9.9 GraphQL deserialization exposing credentials via Duo Chat) and CVE-2026-88765 (CVSS 8.5 Unicode-handling buffer overflow enabling RCE from a crafted Git repository), both shipped in the 10 September release.
2. Hunt for exploitation in access logs. Search GitLab’s Nginx access log — typically at /var/log/gitlab/nginx/gitlab_access.log — for HTTP POST requests to paths matching /api/v4/projects/*/repository/commits/ whose request body contains file.path. Any such request from an unfamiliar source since 11 September 2026 should be treated as a successful read pending investigation.
3. Assume secret disclosure if you were exposed and unpatched since 11 September 2026. If your GitLab instance was internet-reachable during the exploitation window and is not yet patched, treat every secret held on or reachable from the host as compromised: rotate the Rails secret key base, database and SMTP credentials, LDAP bind credentials, OAuth application secrets, GitLab Runner registration tokens, and every personal access token, project access token, and CI/CD job token created before the exposure window. Assume downstream systems whose credentials sat on the GitLab host may also be compromised and rotate there too.
4. Restrict administrative and API access to institutional networks. Self-managed GitLab administrative and API endpoints should not be freely reachable from arbitrary internet sources. Where possible, front GitLab with a reverse proxy that restricts /api/v4/ and /admin to trusted source ranges, or require VPN for API access. This does not fix the vulnerability but reduces the exposure surface for follow-on flaws.
5. Report suspected compromise. Institutions that observe matching log entries, unexplained secret rotations by unknown actors, or downstream credential misuse traceable to a GitLab instance should report the incident so we can correlate across the constituency.

Think a system in the community is affected or compromised?Report an incident