CVE-2026-85706: GitLab Repository Commits API Path Traversal Enables Unauthenticated Arbitrary File Read

Background

GitLab is a widely used DevOps platform combining source code management, CI/CD pipelines, issue tracking, and container registry functionality, deployed both as a self-managed Community Edition (CE) and Enterprise Edition (EE) instance and as a SaaS offering. Self-managed GitLab instances routinely hold an organization’s entire source code history, CI/CD secrets, deployment credentials, and signing keys, making the platform a high-value target: compromising the GitLab server itself, or exfiltrating data from it, can be a direct path to compromising every downstream system the organization builds and deploys.

Technical Mechanism

CVE-2026-85706 is classified under CWE-35, Path Traversal: ’…/…//’ (a variant of classic directory traversal using combined traversal sequences). CISA’s KEV description states that the flaw exists in GitLab’s repository commits API, allowing an unauthenticated user to read arbitrary files due to “improper path confinement and missing authentication enforcement.”

This description points to two compounding issues in the same code path:

1. Missing authentication enforcement — the repository commits API endpoint, which should require an authenticated and authorized session (since commit data is normally scoped to a project a user has access to), can be reached without any authentication at all.
2. Improper path confinement — once reachable, the endpoint accepts a file or path parameter (likely intended to reference a file within a specific commit’s tree) that is not properly confined to the repository’s own directory structure. By supplying traversal sequences (../../../, or the CWE-35-specific pattern combining multiple traversal and separator sequences to defeat naive sanitization filters that only strip simple ../ patterns), an attacker can cause the API to return the contents of files located anywhere on the filesystem that the GitLab application process can read — not just files inside the targeted Git repository.

Combined, these two flaws mean no credentials and no legitimate project access are required: an attacker who can simply reach the GitLab instance’s commits API over HTTP(S) can retrieve arbitrary server-side files.

Real-World Exploitation Evidence

CVE-2026-85706 was added to CISA’s KEV catalog on 2026-09-11, confirming CISA has evidence of active exploitation in the wild as of that date. CISA’s data lists knownRansomwareCampaignUse as “Unknown” — CISA has not confirmed use of this vulnerability in ransomware campaigns at this time. No specific threat actor or named campaign has been publicly attributed to exploitation of this CVE in the data reviewed for this article; the KEV listing confirms active exploitation in the wild, but attribution detail is not yet public.

Impact Assessment

A CVSS score of 10.0 for an arbitrary file read vulnerability — rather than direct code execution — reflects both the unauthenticated, trivially network-exploitable nature of the flaw and the severity of what can typically be read from a GitLab server’s filesystem:

• Secrets exposure: GitLab instances commonly store database credentials, secrets.yml/gitlab-secrets.json (which can contain the instance’s secret keys used to encrypt stored CI/CD variables and other sensitive data), SSH host keys, and TLS private keys on disk. Arbitrary file read against these specific, well-known paths can escalate directly to full compromise of the instance and everything it protects.
• Source code and CI/CD secret exposure: Even without reaching system-level secrets, reading arbitrary repository files or CI/CD configuration can expose proprietary source code, embedded API keys, and deployment credentials.
• Downstream supply-chain risk: Because GitLab typically holds the credentials used to push to production, sign releases, or deploy infrastructure, a successful file-read-to-secrets-exposure chain can be a stepping stone to a broader software supply-chain compromise affecting every downstream consumer of code built through the compromised instance.
• No authentication barrier: the complete lack of required credentials means any network-reachable, unpatched GitLab instance is exposed to any attacker who discovers it, with no need for prior reconnaissance of valid accounts.

Affected Versions

The KEV data does not include an explicit affected-version table. Consult GitLab’s patch release notes (linked in References) for the definitive list of affected CE/EE versions.

Remediation Steps

CISA’s required action is to apply mitigations per vendor instructions, consistent with BOD 26-04 guidance, or discontinue use of the product if mitigations are unavailable.

1. Upgrade GitLab immediately to the patched release identified in GitLab’s security patch announcement (19.3.2 or later, or the corresponding fixed version for your branch).

   # Example: Omnibus GitLab upgrade
   sudo apt-get update && sudo apt-get install gitlab-ee=19.3.2-ee.0
   # Always follow GitLab's official upgrade path documentation for your version

2. Restrict external access to the GitLab instance via firewall or reverse proxy allow-listing while patching is scheduled, particularly for self-managed instances exposed to the internet.
3. Rotate secrets stored in /etc/gitlab/gitlab-secrets.json (or equivalent), database credentials, and any SSH/TLS private keys if there is any indication the instance was exposed prior to patching — assume compromise of these files if the instance was internet-facing and unpatched during the exploitation window.
4. Revoke and reissue CI/CD variables and deployment tokens that could have been exposed via source/configuration file read.
5. Review access and application logs for commits-API requests predating the patch that include path traversal sequences, to scope the investigation.

Detection Guidance

• Web/application access logs: Search GitLab access logs for requests to repository commits API endpoints containing path traversal sequences (../, ..%2F, ....//, or other encoded/combined traversal patterns) in file-path parameters.
• Unauthenticated API access: Flag commits API requests that lack a valid session or API token where such requests are normally expected to require one — this is a strong indicator of attempted or successful exploitation of the missing-authentication component of this flaw.
• File access anomalies: Where available, audit for the GitLab application reading files outside expected repository storage paths, particularly /etc/gitlab/, /opt/gitlab/embedded/, or other system configuration directories.
• Exact IDS/WAF signatures for this specific CVE should be sourced from GitLab’s advisory and current threat-intelligence feeds once published, as specific published signatures were not available in the data reviewed for this article.

Timeline

References

• GitLab Patch Release — 19.3.2
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 — Forensics Triage Requirements Implementation Guidance
• NVD — CVE-2026-85706