CVE-2026-85706 GitLab: Fixed in 19.1.8, 19.2.6, 19.3.2 — Unauthenticated File Read

On September 11, 2026, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog with a three-day remediation deadline. The flaw is rated CVSS 10.0 and lets an unauthenticated attacker read arbitrary files from the GitLab server.

Fixed versions: 19.1.8, 19.2.6 and 19.3.2.

What makes this CVE severe isn't the technique — path traversal is an old classic — but what a GitLab server holds. It isn't just another application server: it's where an organisation simultaneously stores its source code, its CI/CD secrets, its deployment keys and its registry tokens. An arbitrary-read primitive is worth far more there than on any other machine.

The Vulnerability

Vendor description:

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.

Two defects compound, and their conjunction is what produces the 10.0:

1. Improper path confinement — the API doesn't correctly prevent escaping the repository directory.
2. Missing authentication enforcement on that endpoint — the traversal is reachable with no account at all.

Either alone would be serious. Together they yield internet-reachable arbitrary file read for anyone.

Reading the vector correctly

The S:C (scope changed) is what pushes this to 10.0: impact spills beyond the vulnerable component. On a GitLab server that's literal — reading the server's files yields secrets that open third-party systems.

Note the A:N: no availability impact. The flaw doesn't take GitLab down, it does nothing visible. An exploited server keeps running normally. That's exactly what makes detection late.

Affected and Fixed Versions

Both Community Edition and Enterprise Edition are affected. The affected range is wide — it reaches back to 18.7 — so an instance that hasn't been updated in several cycles is very likely vulnerable.

Check your version:

# Self-hosted instance
gitlab-rake gitlab:env:info | grep "GitLab information" -A 3

# Or from any browser, without authenticating
curl -s https://gitlab.example.com/help | grep -i "version"

# Docker / Omnibus
docker exec <container> gitlab-rake gitlab:env:info

GitLab.com is not affected — the SaaS instance is vendor-managed. This CVE targets self-hosted instances, which are precisely the ones organisations deploy to keep their code in-house.

What an Attacker Gains

This is where the reasoning has to go past "file read". On a GitLab server, here's what's readable:

Application secrets

/etc/gitlab/gitlab.rb
/etc/gitlab/gitlab-secrets.json

gitlab-secrets.json holds the keys that encrypt CI/CD variables stored in the database. An attacker who obtains it, combined with database access or a backup, decrypts every pipeline secret in the instance: cloud credentials, registry tokens, signing keys, production access.

Server SSH keys

/etc/ssh/ssh_host_*_key
/var/opt/gitlab/.ssh/authorized_keys

Database configuration

/var/opt/gitlab/gitlab-rails/etc/database.yml

Source code, obviously — including private repositories, since the traversal sidesteps access control entirely.

Runner environment files, which frequently carry registration tokens allowing an attacker to attach a malicious runner to the project — and therefore execute code inside pipelines.

Why this is a supply chain compromise

A compromised GitLab server does not stay a GitLab incident. The secrets sitting on it open production environments, cloud accounts and artifact registries. And an attacker who gains the ability to alter a pipeline can inject code into signed deliverables — the supply chain attack pattern in its most direct form.

Detection

Exploitation raises no visible error, so you have to look in access logs.

Application logs

# Requests to the commits API — hunt for traversal sequences
grep -E "commits" /var/log/gitlab/gitlab-rails/production_json.log \
  | grep -E "\.\.|%2e%2e|%252e"

# Unauthenticated accesses that returned 200 on repository endpoints
jq 'select(.status == 200 and (.username == null or .username == "")) | {time, path, remote_ip}' \
  /var/log/gitlab/gitlab-rails/production_json.log

Encoding forms to watch: ../, %2e%2e%2f, %252e%252e%252f (double-encoded), and Windows-separator variants.

nginx logs

grep -E "%2e|\.\./" /var/log/gitlab/nginx/gitlab_access.log

Post-exploitation indicators

These signals are more reliable than detecting the exploitation itself:

• New personal or project access tokens not tied to any request
• Registered runners nobody recognises: Admin → CI/CD → Runners
• SSH keys or deploy keys added to accounts or projects
• Successful logins from unusual addresses, particularly on service accounts
• Pipeline changes (.gitlab-ci.yml) outside the normal review flow
• Outbound traffic from the GitLab server to destinations unrelated to its declared mirrors and registries

Mitigation

1. Update — this is urgent, not schedulable

# Omnibus (Debian/Ubuntu)
apt-get update && apt-get install gitlab-ce   # or gitlab-ee

# Verify after restart
gitlab-rake gitlab:env:info | head -20

Given the three-day CISA deadline and confirmed exploitation, this is not a monthly-maintenance item.

2. If you can't update immediately

Remove internet exposure. Because the flaw is unauthenticated, cutting public access is a real mitigation, not cosmetic: it reduces the attacker population to your internal network.

# Upstream nginx — restrict the API to trusted networks
location /api/ {
    allow 10.0.0.0/8;
    deny  all;
}

Test before applying: blocking /api/ breaks runners and integrations.

3. If you conclude there was a compromise

Order matters here, because the readable secrets open third-party systems.

1. Rotate application secrets — regenerate gitlab-secrets.json following the vendor procedure (note: this invalidates encrypted CI/CD variables, which will need re-entering)
2. Revoke every token: personal access tokens, project and group tokens, runner registration tokens
3. Rotate secrets exposed in pipelines — cloud credentials, registry keys, signing keys. This is the most important step: those are what grant access to something other than GitLab
4. Audit registered runners and remove any that don't correspond to anything
5. Verify repository integrity: compare recent commit hashes on protected branches against the team's local clones
6. Replace the server's SSH host keys

Don't treat the update as sufficient: it closes the door, it doesn't revoke what already left.

Why Continuous Monitoring of Developer Tooling Matters

GitLab, Jenkins, Artifactory, container registries: this category is poorly covered by vulnerability inventories because it's managed by development teams rather than IT, and it doesn't show up in conventional estate scans. Yet it's precisely the category where a file read turns into production access.

With cveo.tech, inventory your development and CI tooling with exact versions, and get automatic alerts whenever a critical CVE affects one — so a three-day CISA deadline is three days of action, not three days of not knowing.