GitLab commits API path traversal: CVE-2026-85706

Most GitLab advisories assume a signed-in user, a project role or a crafted merge request. CVE-2026-85706 assumed none of those. Under conditions GitLab has not spelled out, a request to the repository commits API with no credentials could read arbitrary files from the server, which on a GitLab host can include configuration files and secrets. GitLab scored it 10.0.

GitLab shipped fixes for three branches on 10 September 2026. CISA added the bug to its Known Exploited Vulnerabilities catalog the next day with a 14 September deadline, and watchTowr reported probes in its honeypots within a day of the patch. On 23 September GitLab backported the fix to two older branches, so the affected range is wider than the first announcement suggested.

Who is affected

GitLab Community Edition and Enterprise Edition, self-managed, from 18.7 onward:

GitLab.com already runs the fix, and GitLab Dedicated customers need take no action. GitLab does not list releases before 18.7 as affected.

GitLab's description of the trigger is only "certain conditions". Some secondary write-ups name a specific project setting as the condition, but GitLab has not confirmed that, so do not treat project visibility as a defense.

How the path traversal works

CVE-2026-85706

GitLab describes two failures in one endpoint: the repository commits API did not confine file paths, and it did not enforce authentication. Together they let a request with no credentials name a path outside where it should be allowed and get the file contents back. NVD classifies the bug as CWE-22, path traversal; CISA's catalog lists CWE-35, a narrower path traversal variant.

GitLab's vector, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, rates integrity high as well as confidentiality, although its description covers file reads only. GitLab credits the researcher s3ntago, who reported it through HackerOne.

Related, not exploited: CVE-2026-97229 and CVE-2026-110264

Two later GitLab bugs share the 10.0 score but work differently. Both are integer overflows in GitLab's regular expression compiler that, under certain conditions, could let an unauthenticated user run code on the server.

• CVE-2026-97229 was fixed on 12 October 2026 in 19.4.2, 19.3.5 and 19.2.8. It affected only 19.2 through 19.4 and involves a crafted regular expression in a CI/CD configuration.
• CVE-2026-110264 was fixed on 21 October 2026 in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Its affected range reaches back to GitLab 7.0.

Neither is in the KEV catalog, and CISA's assessments on NVD record no exploitation for either. GitLab does not describe the second as an incomplete fix for the first. Its published ranges do, however, place the 12 October builds inside CVE-2026-110264's affected range, so an instance patched on 12 October still needs the 21 October release. That conclusion is our reading of the ranges, not a GitLab statement.

Is it being exploited?

CISA added CVE-2026-85706 to the KEV catalog on 11 September 2026, with a due date of 14 September. The entry marks forensic triage as required under BOD 26-04 and lists ransomware use as unknown. GitLab's release post cites the listing but does not describe specific attacks.

watchTowr published a rapid reaction on 11 September saying its honeypot network was already seeing probes for the bug and that it expected indiscriminate exploitation. That is evidence of scanning activity. None of the sources reviewed here publish details of a confirmed compromise.

Check your exposure

On Linux package installations, confirm the version and look at recent traffic to the commits API:

# Shows the GitLab version and environment
sudo gitlab-rake gitlab:env:info
 
# POST requests to the repository commits API
sudo grep 'repository/commits' /var/log/gitlab/gitlab-rails/api_json.log | grep POST
 
# Narrow to watchTowr's pattern: requests carrying a file.path parameter
sudo grep 'repository/commits' /var/log/gitlab/gitlab-rails/api_json.log | grep -F 'file.path'
 
# The same endpoint at the NGINX layer
sudo grep -E 'POST /api/v4/projects/[^ ]+/repository/commits' /var/log/gitlab/nginx/gitlab_access.log

Legitimate tools also post to this endpoint to create commits, so expect some noise. GitLab's API log records the user ID and username for each request, which helps separate anonymous calls from your own automation. Self-compiled installations use bundle exec rake gitlab:env:info RAILS_ENV=production for the version check.

Fix it

Upgrade to the fixed release for your branch; instances on 18.7 through 18.10 should move to 18.11.12 or later. Because CVE-2026-110264 also affects every branch in the table above, the practical target is the 21 October patch release for your branch, which also carries this fix.

GitLab lists no workaround. watchTowr's interim advice is to remove public access to self-managed instances that cannot be patched immediately. If you are following the BOD 26-04 triage guidance, collect logs and other evidence before you patch.

A patch closes the hole but does not undo reads that already happened. If the checks above turn up anonymous requests you cannot explain, treat secrets the GitLab server can read as exposed and rotate them.

Detect attempts and compromise

GitLab's release post names three detections for self-managed instances, without publishing their logic:

• gitlab.yml reads. An attempt to read the gitlab.yml configuration file.
• metadata.path parameter. A file read through a metadata.path parameter.
• File path attempts. A generic file path read attempt.

watchTowr's hunting pattern is different: POST requests to /api/v4/projects/{id}/repository/commits/ that carry a file.path parameter. GitLab's rule names mention metadata.path; watchTowr's pattern mentions file.path. Neither source publishes full indicators, so hunt for both and review every unauthenticated request to the endpoint.

If any of these fired before you patched, treat the instance as compromised. Work through scoping, evidence collection and containment, decide whether files were read, and rotate what was readable.

Beyond this patch

Two lessons outlast this release. Check a vendor's advisory again a week after it ships: here the affected range and the fix list both changed after publication. And keep the secrets a server can read few and easy to rotate, because a file-read bug hands them to whoever finds it first.