On September 10, 2026, GitLab shipped a critical fix for CVE-2026-85706, a path traversal flaw rated 10.0 on the CVSS scale. It lets an unauthenticated attacker read arbitrary files from a self-managed GitLab server. Less than 24 hours later, watchTowr was already seeing probes against internet-facing instances. CISA has added the flaw to its KEV catalog, and a proof of concept is public. On a GitLab server, file read alone can be enough to expose SSH keys, database credentials and CI/CD variables.
- CVE-2026-85706 (CVSS 10.0): unauthenticated arbitrary file read through the repository commits API in GitLab CE/EE.
- Every version from 18.7 onward is affected, up to the fixed releases 18.11.12, 19.0.9, 19.1.8, 19.2.6 and 19.3.2.
- watchTowr saw in-the-wild probes from 06:00 UTC on September 11, 2026. CISA added the flaw to KEV, and Singapore’s Cyber Security Agency reports a public PoC.
- GitLab.com and GitLab Dedicated are already patched. Only self-managed instances need updating.
- The same release fixes CVE-2026-87719 (CVSS 9.9, GitLab EE) and 16 other vulnerabilities.
What GitLab fixed
According to GitLab’s advisory, the flaw comes from improper path confinement and missing authentication enforcement in the repository commits API. Under certain conditions, an unauthenticated user can read arbitrary files on the server. The CVSS 3.1 vector published by the vendor (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N) describes a remote, low-complexity attack that needs no privileges or user interaction, with high confidentiality and integrity impact. The issue was reported by researcher “s3ntago” through GitLab’s HackerOne program.
Affected and fixed versions
| Branch | Vulnerable versions | Fixed version |
|---|---|---|
| 18.7 to 18.11 | From 18.7 up to, but not including, 18.11.12 | 18.11.12 (backport, September 23) |
| 19.0 | Before 19.0.9 | 19.0.9 (backport, September 23) |
| 19.1 | Before 19.1.8 | 19.1.8 |
| 19.2 | Before 19.2.6 | 19.2.6 |
| 19.3 | Before 19.3.2 | 19.3.2 |
GitLab offers no workaround and recommends upgrading every self-managed installation immediately. GitLab.com already runs a patched version, and GitLab Dedicated customers need to take no action.
A second critical flaw in the same release
The release also fixes CVE-2026-87719 (CVSS 9.9), an insecure deserialization issue in the GitLab EE GraphQL subscription serializer. Under certain conditions, an authenticated user with Duo Chat access can obtain the instance’s Advanced Search configuration and sensitive credentials. It affects GitLab EE from 18.3 onward. Sixteen other vulnerabilities are fixed too, six of them rated high.
From patch to probes in under 24 hours
| Date | Event |
|---|---|
| September 10, 2026 | GitLab releases 19.3.2, 19.2.6 and 19.1.8 |
| September 11, 2026, 06:00 UTC | watchTowr reports active in-the-wild probes against unpatched instances |
| September 11, 2026 | CISA adds CVE-2026-85706 to KEV, according to GitLab and Security Affairs |
| September 17, 2026 | Singapore’s Cyber Security Agency reports active exploitation and a public PoC |
| September 23, 2026 | Fix backported to 19.0.9 and 18.11.12 |
According to watchTowr, as quoted by BleepingComputer and Security Affairs, the flaw lets attackers read arbitrary files in a single HTTP request. Press reports also say watchTowr found the only prerequisite to be that the instance hosts at least one public project. That is a common setup for any forge publishing open source code.
There is a precedent. In May 2023, CVE-2023-2825, another GitLab file read flaw rated 10.0, was attacked within days of disclosure.
Why “just” file read is critical
On a GitLab server, configuration files hold the secrets that unlock the rest of the development ecosystem. Security Affairs lists SSH keys, database credentials, deploy tokens and CI/CD variables among the data at risk. With those, an attacker can push code, tamper with pipelines, reach cloud or production environments and move from the forge into the software supply chain.
That is why patching alone is not enough for an instance that was exposed and vulnerable between September 10 and the upgrade. Secrets read before the patch stay valid until they are rotated.
MITRE ATT&CK view
The sources do not provide an ATT&CK mapping. The table below is an indicative Defensy reading based on the attack scenario described.
| Technique | Behavior |
|---|---|
| T1595.002 — Vulnerability Scanning | Probes against exposed GitLab instances observed by watchTowr |
| T1190 — Exploit Public-Facing Application | Unauthenticated request to the commits API to read files |
| T1552.001 — Credentials In Files | Theft of secrets stored in server files |
Recommendations
- ImmediateUpgrade every self-managed instance
Move to 19.3.2, 19.2.6, 19.1.8, 19.0.9 or 18.11.12 depending on your branch. Don’t forget secondary instances (subsidiaries, labs, test environments) that often get missed.
- ImmediateRemove public access until patched
If you cannot upgrade right away, put the instance behind a VPN or IP allowlist, as researchers recommend.
- ImmediateHunt for attempts in your logs
Look for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ carrying a file.path parameter since September 10. GitLab published three detections: a gitlab.yml read attempt, LFI via the metadata.path parameter and an LFI file path attempt.
- Short termRotate secrets if in doubt
If the instance was exposed and vulnerable, rotate SSH keys, deploy and access tokens, CI/CD variables, database credentials and cloud keys referenced on the server, then review their recent use.
- Short termAddress CVE-2026-87719 too
On GitLab EE, the same release fixes the Duo Chat / GraphQL flaw. Review who has Duo Chat access and which credentials sit in the Advanced Search configuration.
- Medium termMove secrets out of the forge
Store CI/CD secrets in a dedicated vault with short-lived tokens, and monitor your forge as a critical asset in the SOC.
An exposed code forge is a gateway to the whole development chain. The gap between patch and exploitation is now measured in hours, so you need to know within minutes which instances are exposed and which version they run.
With IGIDER Strike, we identify your exposed assets and their exploitable vulnerabilities. Our Audit & Offensive Security team assesses your DevOps pipelines, and our SOC helps you analyze logs to find out whether an attempt succeeded.
- GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8GitLab — September 10, 2026, updated September 23, 2026
- Active Exploitation of Critical Vulnerability in GitLab (AL-2026-123)Cyber Security Agency of Singapore — September 17, 2026
- CVE-2026-85706NIST — National Vulnerability Database
- GitLab urges users to patch max severity path traversal flawBleepingComputer — September 11, 2026
- GitLab CVE-2026-85706: One HTTP Request, No Authentication, Full File Read – Exploited Within 24 HoursSecurity Affairs — September 13, 2026
- GitLab CVSS 10 file-read flaw (original article)The Hacker News — September 2026
