Critical GitLab file-read flaw was reportedly exploited soon after disclosure

What happened

GitLab disclosed CVE-2026-85706, a path-traversal vulnerability in its repository commits API, with a reported CVSS score of 10.0. Security reporting says the flaw required no authentication and was being exploited within 24 hours of disclosure.

A crafted HTTP request could allow an attacker to read files that should not be accessible through the API, creating a potential path to sensitive source code, configuration data, or secrets.

The available reporting supports the vulnerability and the rapid exploitation claim, but it does not establish that every exposed GitLab instance was compromised or that every reported target suffered data theft. Organizations should treat externally reachable, affected GitLab deployments as urgent investigation and remediation priorities.

Patching or applying GitLab’s documented mitigation is the first step, followed by checking logs for suspicious requests and reviewing whether files containing credentials or tokens may have been readable. If evidence of access is found, responders should assume exposed secrets may require replacement rather than waiting for proof of misuse.

Why this changes the risk

An unauthenticated file-read vulnerability removes the need for an attacker to possess a valid GitLab account before attempting access. Because GitLab repositories and adjacent configuration files can contain intellectual property, deployment details, or credentials, even a read-only flaw can become a launch point for further compromise.

The reported exploitation shortly after disclosure compresses the response timeline: defenders cannot safely assume that a system was missed simply because it was patched quickly.

Exposure depends on deployment, version, reachability, and the files available to the vulnerable API, so investigation should combine asset inventory, remediation status, and log review rather than rely on the severity score alone.

Find your role

What to do next