CVE-2026-85706

What is GitLab?

GitLab Community Edition (CE) and Enterprise Edition (EE) form a self-hosted DevOps platform combining Git hosting, code review, CI/CD, package registries, and issue tracking. Tens of thousands of organizations run their own instance, and that instance holds the keys to the software supply chain: SSH host keys, the Rails secrets file, database credentials, runner registration tokens, CI/CD variables that often contain cloud API keys, and every private repository. An unauthenticated file read on a GitLab server is therefore rarely "just" information disclosure; it is usually a direct path to signing keys, session forgery, and cloud account takeover.

Overview

CVE-2026-85706 is a CVSS 10.0 path traversal (CWE-22) in the GitLab repository commits API. An unauthenticated attacker can read arbitrary files that the GitLab application user can access with a single HTTP request. GitLab shipped fixes on 2026-09-10; mass exploitation attempts began within hours, and CISA added the CVE to KEV on 2026-09-11 with a three-day deadline. GitLab.com and GitLab Dedicated were patched by GitLab before disclosure; only self-managed instances need action.

Affected Versions

Both CE and EE are affected. The same patch release fixed 17 other vulnerabilities.

Technical Details

The repository commits API (POST /api/v4/projects/{id}/repository/commits) accepts a file.path parameter for actions on files in the target repository. Two defects combined:

• Missing authentication enforcement. The code path handling that parameter was reachable without a valid session or token.
• Improper path confinement. The supplied path was not confined to the repository working tree, so ../ sequences allowed the request to reference arbitrary files on the server that the git application user can read.

The result is an unauthenticated arbitrary file read. Typical targets are /etc/gitlab/gitlab-secrets.json (Rails secret key base and database encryption keys), /etc/gitlab/gitlab.rb, SSH host keys, and runner tokens. With the secrets file an attacker can forge sessions and API tokens, so the flaw is realistically an authentication bypass and full compromise, which is why the CVSS vector carries scope change (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N).

Attack characteristics: no authentication, low complexity, one HTTP request, no user interaction.

Discovery

The vulnerability was reported to GitLab through its HackerOne bug bounty program by the researcher known as s3ntago. GitLab disclosed it in the 2026-09-10 critical patch release.

Exploitation Context

watchTowr's honeypot network began recording exploitation attempts around 06:00 UTC on 2026-09-11, less than a day after the patch. Independent researchers observed the same internet-wide probing, and watchTowr assessed with high confidence that the bug would become indiscriminately exploited given the single-request path. Rapid7 and CISA confirmed in-the-wild exploitation the same day. There is no public attribution to a specific group as of 2026-09-16; the pattern matches opportunistic scanning by multiple actors.

Remediation

1. Upgrade self-managed GitLab immediately to 19.3.2, 19.2.6, or 19.1.8. If you cannot patch within hours, take the instance off the public internet or place it behind a VPN or authenticating proxy until you can.
2. Search access logs (gitlab-rails/production_json.log, nginx/gitlab_access.log) for POST requests to /api/v4/projects/*/repository/commits containing a file.path parameter with traversal sequences, particularly from unauthenticated sources.
3. Assume secrets were read if the instance was exposed and unpatched on 2026-09-11 or later. Rotate gitlab-secrets.json contents (this invalidates existing sessions and re-encrypts stored CI variables, so follow GitLab's documented procedure), database passwords, SSH host keys, runner registration and authentication tokens, and personal access tokens.
4. Rotate downstream credentials stored in CI/CD variables, especially cloud provider keys, container registry credentials, and deploy keys, since those are the highest-value contents of a GitLab server.
5. Review for persistence: new admin users, new personal access tokens, changed webhooks, and unexpected runner registrations created after 2026-09-10.
6. Subscribe to GitLab security release notifications and keep self-managed instances on a supported minor version; the affected range began at 18.7, so instances lagging several releases were exposed longest.