Critical Vulnerability

GitLab CVSS 10 file-read bug probed in the wild

By Yazoul AI · automated

GitLab has released patches to address multiple flaws, including a maximum-severity security vulnerability that has witnessed in-the-wild probes within hours of public disclosure. The vulnerability in

What Happened

GitLab has shipped patches for a batch of vulnerabilities, and one of them stands out: CVE-2026-85706, rated CVSS 10.0, an unauthenticated file-read issue. Within hours of public disclosure, security teams began logging probing activity against exposed GitLab instances from the internet. There is already a public proof-of-concept circulating, which collapses the usual reconnaissance window between patch release and weaponization.

The affected surface is GitLab’s self-managed deployments. GitLab.com is patched by the vendor automatically, but the large install base of on-prem instances, including internal, air-gapped-adjacent, and internet-facing servers, is on operators to remediate.

Why It Matters

GitLab is not just a code repository. For most organizations it is the control plane for the software supply chain: CI/CD runners, registry and secret storage, deployment credentials, and the source of truth for application code. An unauthenticated file-read primitive on that host is a direct path to credentials, tokens, and pipeline secrets. Those are exactly the assets that turn a single vulnerability into a broader compromise of build systems and downstream environments.

The CVSS 10.0 rating reflects that any unauthenticated attacker with network reach can trigger it, with no authentication or user interaction. That is the worst-case combination for a system that usually sits behind a login.

Technical Details

The flaw is an unauthenticated file-read condition, exploited in the wild with a public PoC. It follows a pattern GitLab has been fighting all year: path-handling bugs in components that are reachable before authentication. GitLab previously patched a package-registry path traversal leading to RCE (CVE-2026-10053) and a CSRF issue allowing unauthenticated users to act as anyone (CVE-2026-4922). The same class of bug keeps surfacing: input that crosses a trust boundary before authentication is enforced.

Indicators to hunt for include anomalous GET requests to file-serving endpoints from unauthenticated sessions, requests containing encoded traversal sequences, and outbound connections from GitLab hosts to unfamiliar destinations. If file contents were exfiltrated, secrets may already be in attacker hands, so rotation and not just patching is required.

Immediate Risk

Treat this as urgent and already operational. A public PoC plus observed probes means exploitation is not theoretical. Internet-facing GitLab instances are the highest priority, but do not discount internal ones: attackers who land on a workstation or VPN can reach GitLab the same way. Once file read succeeds, the relevant question shifts from “is there a vulnerability” to “what did they read,” and the honest answer is that you may not know.

Security Insight

The CVSS 10.0 label undersells the real exposure. The read primitive is not the finish line, it is the reconnaissance step: secrets harvested from one GitLab instance become valid credentials against staging, production, and third-party services. This mirrors the 2021 Codecov and 2022 CircleCI incidents, where credentials exfiltrated from CI/CD tooling were used to pivot across many customer environments long after the initial bug was closed. Patch immediately, then rotate every secret the repository, runner, or registry could have exposed. A patched GitLab with unrotated tokens is still a compromised one.

Further Reading

Share:

Never miss a security update

Get real-time security alerts delivered to your preferred platform.

Related News

Related Across Yazoul

Never Miss a Critical Alert

CVE advisories, breach reports, and threat intel — delivered daily to your inbox.