GitLab CVE-2026-85706: the CVSS 10 file-read flaw under attack, and why patching is only half the fix

CVE-2026-85706 is a critical path traversal vulnerability in self-managed GitLab Community and Enterprise Editions, rated CVSS 10.0. An unauthenticated attacker can read arbitrary files from the server through the repository Commits and Files APIs. GitLab fixed it on 10 September 2026 in versions 19.1.8, 19.2.6 and 19.3.2, and CISA added it to its Known Exploited Vulnerabilities catalogue the next day. If your GitLab was reachable from the internet on an affected version, upgrading is necessary but not sufficient: the secrets it held should be treated as exposed.

A source code server is one of the most valuable machines a company runs. It holds the code, and through CI/CD it also holds the keys to production: cloud credentials, registry tokens, deploy keys and database passwords. A file-read bug on that server is a credentials leak.

CVE-2026-85706 at a glance

Timeline

A KEV listing within a day of the patch is unusually fast. It means exploitation was either already happening or began as soon as the fix revealed where to look. In practice, the window between patch and attack for internet-facing GitLab is now measured in hours.

How many GitLab servers were exposed?

Cybernews, citing internet-scanning data, reported more than 86,000 GitLab servers exposed online, and data from the Shadowserver Foundation indicating that at least 13,700 of them remained vulnerable to CVE-2026-85706, with the largest share in the United States. Those are point-in-time counts and they fall as administrators patch, but they show the scale: tens of thousands of organisations run GitLab on the open internet, and thousands had not patched weeks after an actively exploited CVSS 10 fix was available.

No public figure for the number of organisations breached through this flaw was available as of 25 October 2026. Reporting describes attackers exfiltrating secrets from GitLab instances, including credentials for cloud accounts, container registries and repositories, rather than taking servers offline. That is typical of a file-read flaw: the damage is quiet and shows up later, somewhere else.

The root cause

Path traversal is one of the oldest web vulnerability classes. An application builds a file path from user input, and the input contains sequences such as ../ that walk out of the intended directory. Here, according to the analyses, a specially crafted HTTP POST request with a file.path parameter to the repository Commits or Files API could escape the repository and reach any file readable by the GitLab process. Rapid7 summarises the cause as improper path confinement combined with missing authentication enforcement on that path.

Missing authentication is what turned a bug into a CVSS 10. A path traversal that needs a logged-in developer is serious. One that needs nothing but network access to the GitLab web interface lets anyone who can reach the server run it.

What an attacker can read

Orca's analysis lists what is typically within reach of the GitLab process: database credentials, SSH keys, deploy tokens, CI/CD variables and configuration files. On a standard Omnibus installation, that includes the main configuration in /etc/gitlab and the file holding GitLab's own encryption secrets. With those, an attacker who also obtains database access can recover encrypted values such as CI/CD variables.

• Cloud provider keys stored as CI/CD variables, which lead directly to production infrastructure.
• Container registry and package registry tokens, which allow malicious images or packages to be pushed.
• Deploy keys and deploy tokens with write access to repositories.
• SMTP, LDAP and object-storage credentials kept in GitLab's configuration.
• Runner registration and authentication tokens, which can be used to register a runner that receives jobs and their secrets.

How to check whether you are affected

# Installed version (Omnibus)
sudo gitlab-rake gitlab:env:info | grep -i 'GitLab information' -A2
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Docker
docker exec <gitlab-container> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

You are affected if the version is 18.7 to 19.1.7, 19.2.0 to 19.2.5, or 19.3.0 to 19.3.1. GitLab.com is operated by GitLab; this advisory is about self-managed installations, including Docker and Helm deployments, which their owners must upgrade.

How to respond: upgrade, then rotate

1. 1

   Upgrade

   Move to 19.1.8, 19.2.6, 19.3.2 or a later patch release on your line. Follow GitLab's upgrade path; skipping required stops between versions breaks background migrations.

2. 2

   Take a backup first

   Run a GitLab backup and copy the configuration and secrets files separately; the application backup does not include them.

3. 3

   Reduce exposure

   If GitLab does not need to be public, put it behind a VPN or an IP allowlist. Most internal GitLab servers have no reason to be on the open internet.

4. 4

   Rotate secrets

   If the server was reachable and unpatched at any point since early September, rotate CI/CD variables, deploy and access tokens, runner tokens, and credentials in the configuration. Start with cloud and registry credentials.

5. 5

   Review what changed

   Look for new runners, new deploy keys, new access tokens and unexpected pipeline changes, and check registries for images pushed by unfamiliar tokens.

Indicators to search for

Check GitLab's API logs for unauthenticated requests to the repository commits and files endpoints whose file path parameter contains traversal sequences such as ../ or their URL-encoded forms. Repeated requests from one address cycling through common file names are a strong sign of automated exploitation. The absence of such entries is not proof of safety if logs were rotated or the requests were obfuscated, so make rotation the default rather than the exception.

Rotating secrets without breaking every pipeline

Rotation is where most teams stall, because every secret is used somewhere and nobody wants to break the release pipeline during an incident. The way through is to rotate in order of blast radius, one class at a time, and to test a pipeline after each class rather than at the end.

For each class, create the new secret, update its consumers, run one pipeline that uses it, and only then revoke the old one. Record what was rotated and when; if suspicious activity appears later in a cloud account, that record tells you whether the credential used was one that leaked.

Hardening after the incident

• Restrict the GitLab web interface to a VPN or known IP ranges unless outside collaborators genuinely need it.
• Enforce two-factor authentication for all users and require admin mode for administrative actions.
• Mark CI/CD variables as protected and masked, and scope them to the environments that need them.
• Prefer short-lived credentials, such as OIDC federation from pipelines to cloud providers, over long-lived keys stored as variables.
• Subscribe to GitLab's security release notices and set a patch target in days, not weeks, for critical releases.
• Keep GitLab's configuration and secrets file backed up separately and encrypted, because a restore without them cannot decrypt stored secrets.

This has happened before

GitLab has had critical, actively exploited flaws before. In January 2024, CVE-2023-7028 allowed account takeover by sending password reset emails to an unverified address, another CVSS 10 issue later added to CISA's KEV catalogue. The pattern repeats: self-managed GitLab instances that are internet-facing and patched on a slow cycle get found and exploited.

The practical answer is not to stop self-hosting. It is to treat GitLab as production infrastructure: subscribe to its security release notices, keep it on a supported version with patch windows measured in days, keep it off the open internet where possible, and keep CI/CD secrets short-lived so a leak expires on its own.