GitLab urges patching CVSS 10.0 pre-auth path traversal CVE-2026-85706 under active scanning

What happened

GitLab has shipped an emergency round of patch releases — 19.1.8, 19.2.6 and 19.3.2 — closing a maximum-severity flaw tracked as CVE-2026-85706. According to BleepingComputer, which reported the advisory on September 11, 2026, the vulnerability scores a perfect 10.0 on the CVSS scale and lets an unauthenticated, network-based attacker read files from self-managed GitLab Community and Enterprise Edition servers. The same critical patch release also addresses a second issue, CVE-2026-87719.

The patching window is already tight. SecurityWeek reported that exploitation attempts were seen one day after disclosure, and security firm watchTowr observed live reconnaissance requests hitting real GitLab deployments, according to a technical breakdown of the incident published on dev.to. To date, only scanning has been publicly confirmed: no successful file read, credential theft or follow-on compromise in a victim environment has been reported.

How the attack works

The dev.to analysis lays out the attack chain against the commit API:

1. The attacker scans for self-managed GitLab instances reachable from the internet.
2. An unauthenticated request is sent to the commit API with a file.path parameter pointing outside its intended scope — a classic path traversal.
3. If the vulnerable conditions are met, the server returns the contents of local files.

From there, the impact depends on what the readable files contain. Configuration files and logs often hold access tokens; valid credentials could open the door to repositories, CI/CD variables, artifacts and runners, and potentially to integrated cloud services through downstream development and deployment pipelines. The attack requires no user interaction and produces nothing visible in the GitLab interface, so it cannot be caught through normal usage.

Patching and containment

The primary fix is straightforward: update to 19.1.8, 19.2.6 or 19.3.2 or later, matching your release series. Until that is possible, the dev.to analysis suggests restricting API access to known sources via VPN or allowlists, and limiting file permissions and the storage scope of sensitive information to reduce the impact of any successful read.

For admins who suspect exposure, the guidance is to revoke and reissue access tokens, runner credentials and keys for external services, following each issuer's procedures. One caveat stands out: GitLab's database encryption keys must not be rotated the way ordinary tokens are. The official Linux package instructions exclude the gitlab_rails keys in gitlab-secrets. from simple rotation, so teams should verify backups and decryption feasibility, and consult product support before touching them.

What to check in the logs

The clearest indicator is unauthenticated POST traffic to the commit API containing path traversal expressions in the file.path parameter. Because that parameter travels in the request body, URLs alone are not enough — reverse proxy or application logs that capture request bodies are needed. Other threads to pull: unusual reads of configuration and log files by the GitLab process, token usage from unfamiliar origins, runner registrations, project enumeration, repository clones, CI variable views, pipeline changes and artifact retrieval.

Reconstructing the exposure period means confirming the GitLab version in use, when it was patched, the oldest anomalous request and response sizes. Large responses alone do not prove that data left the server, and a successful file read is not equivalent to code execution on the host — but neither can be ruled out from logs alone.

Why it matters

A pre-authentication, CVSS 10.0 path traversal on widely deployed self-hosted development infrastructure is about as bad as attack surface gets. GitLab instances concentrate source code, CI/CD secrets, deploy keys and runner tokens, so a single file read can cascade into supply-chain and cloud compromise. With scanning observed within roughly 24 hours of disclosure, every internet-exposed, unpatched instance should be treated as probed. Patch first, then audit the exposure window, investigate any anomalous commit API traffic, and rotate anything that could plausibly have been read.