GitLab Under Attack: Critical Arbitrary File Read Vulnerability

This week’s CVE of the Week is CVE-2026-85706, a critical path traversal vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE) with a maximum CVSS score of 10.0. The vulnerability affects the repository commits API and, under certain conditions, allows an unauthenticated attacker to read arbitrary files from the GitLab server.

CVE-2026-85706 is classified as an “Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)” vulnerability.

The issue is located in GitLab’s repository commits API. GitLab describes the root cause as a combination of improper path confinement and missing authentication enforcement. As a result, under certain conditions, an unauthenticated user can cause the application to access files outside the intended repository path.
In practical terms, the attack can be performed remotely over the network, requires no privileges or user interaction, and can result in a high impact to confidentiality and integrity.

How does the vulnerability work?

The affected repository commits API accepts file-related parameters as part of repository operations. Normally, these paths should remain confined to the relevant repository. The vulnerability occurs because the affected functionality does not adequately enforce authentication and does not properly restrict the supplied path to the intended directory. An attacker can therefore manipulate the path using directory traversal techniques to make the server access files outside the expected repository boundary.

This turns what should be a repository-level file operation into an arbitrary file-read primitive. The security impact depends on what files are accessible to the GitLab process. Of particular concern are GitLab configuration and secret files, which can contain credentials, cryptographic material, tokens, and other information that could potentially be used for further compromise.
Security researchers have reported attempts to retrieve GitLab configuration files, log files, and SSH-related information from vulnerable instances.

Why is this vulnerability so serious?

The CVSS 10.0 rating is significant on its own, but the real concern is the combination of several factors:

• No authentication required
• Remote exploitation
• Low attack complexity
• No user interaction
• Arbitrary file disclosure
• Potential exposure of credentials and secrets
• Potential access to source code and CI/CD-related information
• Confirmed exploitation in the wild

For an enterprise GitLab deployment, exposed secrets can potentially become a stepping stone to additional systems. Credentials, tokens, SSH configuration, or CI/CD secrets obtained from the GitLab host could provide opportunities for lateral movement or further compromise, depending on the individual environment.

Exploitation in the wild

This vulnerability moved particularly quickly from disclosure to active exploitation.
GitLab released its critical patch on September 10, 2026. On September 11, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, confirming active exploitation.
Also reported that in-the-wild probing began shortly after public disclosure. Subsequent observations indicated attempts to identify vulnerable GitLab instances and retrieve sensitive configuration and SSH-related files. This is particularly relevant for internet-facing, self-managed GitLab deployments.

Affected Versions

The vulnerability affects GitLab CE and EE installations in the following release ranges:

Affected versions

• 18.7 through 19.1.7 — Fixed version: 19.1.8
• 19.2.0 through 19.2.5 — Fixed version:19.2.6
• 19.3.0 through 19.3.1 — Fixed version:19.3.2

GitLab confirmed that GitLab.com and GitLab Dedicated are already patched, while self-managed installations require administrators to apply the appropriate security release. The affected deployment types include Omnibus, source-code installations, and Helm chart deployments.

How to protect against CVE-2026-85706

Organizations running affected self-managed GitLab instances should upgrade immediately to one of the fixed versions.

If immediate patching is not possible, restricting public access to the GitLab instance can reduce exposure, although this should be considered a temporary mitigation rather than a replacement for applying the vendor patch.

Because exploitation has already been observed, organizations should also investigate their GitLab and reverse-proxy logs for suspicious requests targeting the repository commits API. GitLab has published specific threat detections for CVE-2026-85706 exploitation attempts, including detections for local file inclusion attempts and malicious file-path parameters.

If exploitation is suspected, simply installing the patch may not be sufficient. Security teams should investigate whether sensitive configuration files, credentials, tokens, or SSH-related information were accessed and consider rotating potentially exposed secrets.

References:

https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/

https://github.com/advisories/GHSA-f47w-mrg9-g9p2

https://www.rapid7.com/blog/post/etr-cve-2026-85706-critical-gitlab-path-traversal-exploited-in-the-wild/

https://thehackernews.com/2026/09/gitlab-cvss-10-file-read-flaw-draws-in.html

https://denizhalil.com/2026/09/15/cve-2026-85706-gitlab-arbitrary-file-read-vulnerability/

https://app.opencve.io/cve/CVE-2026-85706

https://nvd.nist.gov/vuln/detail/cve-2026-85706

Do you want to be protected from attacks like the above? See our defensive services here: Managed Security – White Hat IT Security