GitLab CVE-2026-85706: CVSS 10 Arbitrary File Read

What is CVE-2026-85706?

It is a path traversal in the commits API (/api/v4/projects/{id}/repository/commits/). GitLab describes "improper path confinement" and "missing authentication enforcement." The result is arbitrary file read without an account. The flaw gives file access rather than direct code execution: the secrets in those files open the next step.

According to watchTowr, the only condition is that at least one public project exists on the instance. That is true of most self-hosted instances that publish documentation, a mirror or an open source project. The researcher s3ntago reported it through HackerOne.

Which versions are affected?

GitLab CE and EE from 18.7 through 19.1.7, from 19.2.0 through 19.2.5, and from 19.3.0 through 19.3.1. The fixes are 19.1.8, 19.2.6 and 19.3.2. There is no patch for the 18.x and 19.0 branches: you must move to 19.1.8 at minimum. GitLab offers no workaround. GitLab.com is already patched and GitLab Dedicated customers need take no action. The same release also fixes CVE-2026-87719 (CVSS 9.9, deserialization in GitLab EE: an authenticated user with Duo Chat access can obtain Advanced Search configurations and credentials through a crafted GraphQL subscription argument).

How is it exploited?

Attackers go for configuration files and logs, which contain application keys, database credentials, integration tokens and session fragments. watchTowr saw probes from 06:00 UTC on September 11, one day after the fixes shipped, then extractions of configuration files and system SSH configurations. A public exploit exists. This is a second critical episode after the GraphQL injection CVE-2026-19478: the gap between disclosure and exploitation is measured in hours.

How do you detect exploitation?

The short answer: look for POST requests to the commits API containing a file.Path parameter.

• In HTTP logs and GitLab logs, search for POST /api/v4/projects/{id}/repository/commits/ with file.Path holding absolute paths or directory traversal sequences.
• Treat any occurrence before the patch was installed as a potential secret leak.
• Watch for unusual access to the resources those secrets protect: database, container registry, CI integrations, artifact repositories.

Why does a file read matter so much? A GitLab server stores its own secrets in readable files: the application secrets file, database settings, and integration keys. With them an attacker can often forge sessions, decrypt stored values or log in to connected systems, which turns a read primitive into a full compromise of the code and the pipelines that build it. The advertised CVSS of 10.0 reflects this reach: no account, no interaction, and a network path is enough.

How do you fix and contain it?

1. Upgrade to 19.1.8, 19.2.6 or 19.3.2.
2. Rotate readable secrets: the fix stops new reads, it does not recall what was already copied. That covers application secrets, database credentials, integration tokens, exposed CI variables and SSH keys.
3. Reduce exposure: a self-hosted instance has no reason to be reachable from the internet without a business need. Put it behind a VPN or an admin gateway.
4. Reduce the value of readable files: pipeline secrets in an external manager, logs free of credentials, regular rotation of instance tokens.
5. Also apply the fix for CVE-2026-87719 if you run GitLab EE.

Also review who can create public projects, since the exploit needs one to exist; limiting that setting does not replace the patch but narrows the exposure. Our article on secrets forgotten in Git history covers hunting exposed keys in repositories.

What changes when an AI agent has access to GitLab?

An AI agent that reads or writes in GitLab holds tokens whose leak grants the same rights as its tools, and its context contains content from the repository. Four consequences.

The agent's tokens are prime targets. Code review, ticket triage and patch generation agents use personal or project access tokens, sometimes with write rights and the ability to trigger pipelines. A read of configuration or CI variables exposes them. Our article on the API key exposed to all reporters in the GitLab AI Gateway illustrates this risk.

Repository content is untrusted input. A merge request description, a comment or a file can contain instructions the agent reads as direction. This is indirect prompt injection (dedicated page). Combined with write rights, it can modify code, a pipeline or variables.

The agent amplifies read access. With a stolen token, an attacker can ask a compromised agent to walk hundreds of projects and summarize the secrets it finds, faster than a human could.

Automation turns a mistake into an incident. An agent allowed to merge or deploy without approval carries a malicious change into the pipeline.

Useful measures: minimal-scope, short-lived tokens, read-only by default, no secrets in variables reachable by the agent, human approval before merge or deployment, and logging of every tool call. This maps to LLM06 (Excessive Agency) in the OWASP Top 10 for LLM Applications. See also our page on AI agent security.

How do you test your exposure?

Inventory the reachable GitLab instances, the tokens your agents hold and the rights attached to them. Our Agent Red Team Express (EUR 1,900, 5 days) attacks a real agent with its tools and credentials, including access to a code repository, and delivers a report with reproducible evidence.