Now Detecting: CVE-2026-85706 - Unauthenticated Arbitrary File Read in GitLab

A maximum severity flaw in GitLab's repository commits API allows anonymous attackers to read arbitrary files from self-managed servers. We are already detecting it.

What's the vulnerability?

CVE-2026-85706 is a path traversal vulnerability in GitLab Community Edition and Enterprise Edition, reported by the researcher s3ntago through GitLab's HackerOne bug bounty program. It carries a CVSS score of 10.0, the highest possible rating. It requires no major preconditions and can be exploited by an anonymous, unauthenticated attacker.

The root cause sits in the repository commits API: improper path confinement combined with missing authentication enforcement, which under certain conditions allows an unauthenticated user to read arbitrary files from the GitLab server.

Given that GitLab instances sit at the centre of most software delivery pipelines, any self-managed deployment reachable from an untrusted network should be patched immediately.

PoC

Our current unauthenticated PoC requires a public project to be present and can only read certain files. If a credential contains a % that isn't a valid hex escape, it and the surrounding file contents, can be read unauthenticated. Other mechanisms may exist to read arbitrary files without these constraints, potentially escalating to RCE.

Here's an example video of such an exploit running:

Which versions are affected?

• GitLab CE/EE 18.7 through 19.1.7
• GitLab CE/EE 19.2 through 19.2.5
• GitLab CE/EE 19.3 through 19.3.1
• Gitlab.com and GitLab Dedicated are not affected

What should you do?

Upgrade immediately to a patched version:

• GitLab 19.3.2
• GitLab 19.2.6
• GitLab 19.1.8

Note that this patch includes database migrations. Single-node instances will incur downtime while they complete. Multi-node deployments can follow GitLab's zero-downtime upgrade procedure.

Can't upgrade right away? No workaround has been published, so the only available measure is to reduce reachability:

• Place the instance behind SSO, a VPN, or an IP allowlist
• Restrict access to the commits API at your WAF or reverse proxy: /api/v4/projects/*/repository/commits*

Both measures may affect legitimate functionality and are not 100% effective, therefore, should only be used until you can patch. If the instance was exposed while unpatched, rotate secret_key_base, database credentials, CI/CD variables, runner registration tokens, access tokens, and deploy keys.

How Ethiack helps

Our continuous testing now detects CVE-2026-85706 across your attack surface. It will identify GitLab instances, including those outside your known inventory, and validate exploitable vulnerabilities, so you know exactly where you're exposed and what needs fixing.

References:

• GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8
• GitLab Zero-Downtime Upgrades
• GitLab Instance Security Best Practices
• Cve.org Record