CVE-2026-85706: GitLab repository commits API lets unauthenticated users read files

01

What the vulnerability does

GitLab's advisory says that, under certain conditions, an unauthenticated user could read arbitrary files from the GitLab server, due to improper path confinement and missing authentication enforcement in the repository commits API. GitLab scores it CVSS 3.1 10.0.

CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on 11 September 2026 and marks it for forensic triage. GitLab's published detections look for unauthenticated POST requests to /api/v4/projects/:id/repository/commits or /repository/files carrying a metadata.path or file.path parameter, including attempts to read gitlab.yml, secrets.yml, database.yml and gitlab-secrets.json.

GitLab does not list the conditions. Orca reports that one public project on the instance is enough, and that attackers go after database credentials, SSH keys, deploy tokens, CI/CD variables and configuration files.

02

Affected and fixed versions

From GitLab's patch release. GitLab says that when no deployment type is named, all types are affected, which includes the Helm chart. GitLab.com is already patched and GitLab Dedicated customers need no action.

• Affected: all versions from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.
• Fixed: 19.3.2, 19.2.6 and 19.1.8, released 10 September 2026; 19.0.9 and 18.11.12, backported on 23 September 2026.
• Versions before 18.7 are outside the affected range the advisory gives.
• The advisory lists no workaround.

03

Find GitLab in your clusters

Find the GitLab pods, read the version from the image tag, and check whether a Service or Ingress puts the instance in front of networks you do not control. The flaw needs no account, so any address that reaches the web interface is enough.

kubectl get pods -A -o custom-columns=\
NS:.metadata.namespace,POD:.metadata.name,\
'IMAGE:.spec.containers[*].image' | grep -i gitlab

kubectl get svc,ingress -A | grep -i gitlab

04

What Kubernetes can show, and what is the reliable check

The Kubernetes API shows the version and the exposure. It cannot show whether files were read: the read is an HTTP request answered by GitLab's own process, which starts no new process and changes no Kubernetes object, so process activity on the node will not show it either.

The reliable check is GitLab's API log, api_json.log, which GitLab's detections are built on. On Helm chart installs it is on the Webservice pods under the subcomponent "api_json" key; on Linux package installations it is /var/log/gitlab/gitlab-rails/api_json.log. kubectl logs only returns what the current container still holds, so search your log store for older requests.

# Helm chart: Webservice pods
kubectl logs -n <ns> <webservice-pod> \
  --all-containers | grep api_json \
  | grep -iE 'repository/(commits|files)' \
  | grep -iE '(metadata|file)(\.|%2e)path' \
  | grep -vE '/uploads/tmp/|/tmp/gitlab/'

# Linux package installation in a pod
kubectl exec -n <ns> <pod> -- grep -iE \
  '(metadata|file)(\.|%2e)path' \
  /var/log/gitlab/gitlab-rails/api_json.log

05

Fixing it

Upgrade to 18.11.12, 19.0.9, 19.1.8, 19.2.6 or 19.3.2, or later. GitLab recommends upgrading all affected self-managed installations immediately.

Upgrading does not undo a read that already happened. If the log shows requests that named files like gitlab-secrets.json or database.yml, treat the secrets in them as exposed and rotate them.