GitLab patches a CVSS 10 arbitrary file-read flaw, exploited within 24 hours
On September 11, 2026, GitLab shipped an out-of-band release for CVE-2026-85706, a CVSS 10 path traversal that reads server files with no authentication via the commits API. The flaw is already being probed in the wild — patch self-managed instances before an attacker reads secrets.yml.
September 11, 2026. GitLab shipped an out-of-band security release to fix CVE-2026-85706, a path traversal rated CVSS 10.0 in the repository commits API. The flaw lets an unauthenticated attacker read any file on the GitLab server with a single HTTP request — including the database encryption keys. Less than 24 hours later, attack-surface management firm WatchTowr observed in-the-wild probes.
The stakes match the score: GitLab reports more than 30 million registered users and powers over half of the Fortune 100, including Nvidia, Airbus, and Goldman Sachs. An arbitrary file-read on that install base is a potential supply-chain risk for the software those organizations build and ship.
A path traversal in the commits API
The vulnerability was reported through GitLab’s HackerOne bug bounty program by a researcher using the handle s3ntago. It lives in the commits API, the endpoint that CI/CD pipelines, automation scripts, and third-party integrations rely on to interact with version-control data.
The normal flow: when a call arrives to retrieve commit data or file diffs, the Ruby on Rails backend passes the requested path to Gitaly, its in-house RPC wrapper around Git. Sanitization routines are supposed to keep that path confined to the repository’s directory tree. In affected versions, the commits API fails to strip traversal sequences such as ../ or their URL-encoded variants. Per GitLab’s advisory, the flaw combines improper path confinement with missing authentication enforcement — under specific, undocumented conditions the access check is bypassed, so no credentials, private tokens, or prior user interaction are required.
From file read to full takeover
Reading arbitrary files off a self-managed GitLab server is not just a data leak: it is the first step toward a full compromise. The logical targets are /etc/passwd, but above all secrets.yml and gitlab.rb — the files holding the encryption keys for database columns and session cookies, along with the PostgreSQL database credentials.
Once secrets.yml is exfiltrated, the attacker reaches the database directly, elevates to GitLab administrator, then injects malicious code into CI/CD pipelines — the classic vector for a software supply-chain attack. For any organization storing proprietary code, AI models, or infrastructure templates on an affected server, the flaw is a direct path to intellectual-property theft. The technique is not new: CVE-2023-2825, a similar traversal, already targeted secrets.yml.
CVE-2026-87719, the second fix in the bundle
The out-of-band release also patches CVE-2026-87719, an insecure deserialization rated CVSS 9.9 affecting Enterprise Edition instances that use Duo Chat, the generative coding assistant. The defect sits in the GraphQL subscription serializer: an authenticated attacker submits a crafted subscription argument that bypasses serialization controls and forces the backend to resolve an out-of-scope object reference.
The primary target is Advanced Search configuration and the credentials of the indexing engines (Elasticsearch or OpenSearch). By manipulating the serializer, a user with basic Duo Chat access can drive the backend to dump those credentials, opening up the entire indexed codebase, internal wikis, and issue trackers — regardless of repository-level permissions. Less publicized than CVE-2026-85706 because it requires authentication, it is no less critical for anyone running Duo Chat.
Exploited within 24 hours, and what that changes
The disclosure-to-exploitation gap is the defining fact here. WatchTowr reported active probes the very next day, and CISA listed the flaw in its KEV catalog. That rhythm — disclose, weaponize, probe in under a day — has become the norm for CVSS 10 flaws on products this widely deployed: the patch no longer outruns the attacker, it trails them by hours.
For a CISO or an SRE, the consequence is direct: a self-managed GitLab instance exposed on the evening of September 11 without the patch should be treated as potentially already read. The patch removes the flaw, not any access gained in the meantime.
Verdict
If you self-host GitLab, apply 19.1.8, 19.2.6, or 19.3.2 immediately — the flaw affects all versions 18.7 through 19.1.7, 19.2 through 19.2.5, and 19.3 through 19.3.1. Until you have confirmed the instance was not exposed, rotate the secrets.yml keys, the database credentials, and the integration tokens. If the instance was reachable from the internet on disclosure day, run an incident review: access logs, newly created accounts, modified pipelines.
If you use GitLab.com, the managed platform was patched server-side and you have nothing to do — but your self-managed mirrors, runners, and integrations were not. The lesson extends to the whole DevSecOps ecosystem: an arbitrary file-read on a software forge is not an isolated security incident, it is the entry point for a supply-chain compromise. Patch before you count the days.
References
- The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure, September 11, 2026
- SecurityWeek — GitLab Vulnerability Exploited One Day After Disclosure
- The CyberSec Guru — GitLab CVE-2026-85706: Critical CVSS 10.0 Path Traversal Flaw, September 11, 2026
- NVD — CVE-2026-85706
- NVD — CVE-2026-87719