CISA confirms exploitation of GitLab's CVSS 10 file read flaw CVE-2026-85706

GitLab CVE-2026-85706 is a path traversal flaw in the repository commits API that lets an unauthenticated user read arbitrary files from a self-managed GitLab server. GitLab fixed it on September 10, 2026 in versions 19.3.2, 19.2.6 and 19.1.8 for Community Edition and Enterprise Edition, and told self-managed customers to upgrade immediately.

The release fixes 18 security issues. Two are rated critical. Per GitLab's patch release blog, the root cause of the headline bug is improper path confinement combined with missing authentication enforcement on that API. GitLab assigned it a CVSS v3.1 base score of 10.0, the maximum.

The issue came in through GitLab's HackerOne bug bounty programme, credited to the researcher s3ntago. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, which reads as network reachable, low complexity, no privileges and no user interaction.

Path traversal is a class of bug where an application accepts a file path from a request and fails to keep it inside the directory it's supposed to serve. Feed it the right sequence and the application reads a file somewhere else on disk.

In GitLab's case, two problems stack on the same endpoint. The path isn't properly confined, and authentication isn't enforced on the affected route. So the request doesn't need credentials to come back with file contents.

watchTowr, which reproduced the issue and published a Rapid Reaction write-up on September 11, says a single HTTP request is enough to read a file. Jake Knott, its head of threat intelligence, told The Hacker News that exploitation has one prerequisite: at least one public project must exist on the instance.

No public exploit code, indicator list or attacker infrastructure has been published by GitLab, CISA or watchTowr at the time of writing.

CVE-2026-85706 affects GitLab CE and EE across three ranges, per the vendor advisory. That covers a long tail of instances that skipped the last few patch cycles.

• All versions from 18.7 before 19.1.8
• All versions from 19.2 before 19.2.6
• All versions from 19.3 before 19.3.2

Deployment type doesn't change the exposure. GitLab notes that when no specific deployment type is named, all of them are affected: Linux package, source install, Helm chart and containers alike.

The real risk multiplier is reachability. An instance published to the internet can be read by anyone who finds it. One behind a VPN or a zero trust proxy still needs the patch, but the window for an opportunistic scan is much smaller.

CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on September 11, 2026, based on evidence of active exploitation. Federal Civilian Executive Branch agencies were given until September 14, 2026 to remediate.

The entry also carries forensic triage requirements under Binding Operational Directive 26-04. That's the part worth reading if you're not a US federal agency. CISA is signalling that vulnerable systems may have been accessed before the patch landed, so patching alone doesn't close the incident.

CISA lists known ransomware use as unknown. No named threat actor has been tied to the activity in public reporting, and the agency hasn't attributed it.

watchTowr's first report described behavioural probes against its global honeypot network, meaning someone had already reverse engineered the fix and rebuilt a working request. That was roughly a day after the patch, from around 06:00 UTC on September 11 per the firm's statement to The Hacker News.

Knott's later update went further. He said attackers moved from identifying vulnerable instances to successful exploitation and exfiltration, with config files dumped for secrets alongside system SSH configurations. That pairing matters: credentials plus SSH config can turn a file read into interactive access where password authentication is allowed.

Rapid7, which also covered the release, recommends looking for signs of compromise even after the update is applied. Of the 18 CVEs in this patch, only CVE-2026-85706 is known to be exploited so far.

CVE-2026-87719 is the second critical fix, rated CVSS 9.9 and limited to Enterprise Edition. GitLab says an authenticated user with Duo Chat access could obtain Advanced Search instance configurations and sensitive credentials through a crafted GraphQL subscription argument that bypasses serialization and performs a server object lookup. Rapid7 classifies it as insecure deserialization, CWE-502.

It affects EE from 18.3 before 19.1.8, 19.2 before 19.2.6 and 19.3 before 19.3.2. The same three patch versions fix it. There's no public report of exploitation.

Context from watchTowr: this is the second critical GitLab flaw in recent weeks, after a GraphQL code injection issue tracked as CVE-2026-19478 that was attacked almost immediately after disclosure.

Start with an inventory. Find every self-managed GitLab instance, including staging, standby and disaster recovery copies, and record the running version and whether it's reachable from the internet.

1. Upgrade to 19.3.2, 19.2.6 or 19.1.8 depending on your branch, as an emergency change.
2. Pull any instance you can't patch within hours off the public internet first.
3. Hunt your commits API logs for exploitation attempts before assuming you're clean.
4. Rotate every secret a file read could have exposed on an instance that was public.
5. Preserve logs and take a configuration backup for forensics, without delaying the upgrade.

This patch includes database migrations, so single node installs will take downtime while they run. Multi node deployments can follow GitLab's zero downtime procedure.

For the hunt, watchTowr suggests reviewing logs for HTTP POST requests to the commits API carrying file path parameters. Check GitLab Rails and production logs together with NGINX, reverse proxy and WAF telemetry.

POST /api/v4/projects/{id}/repository/commits/ ... file.path=

watchTowr assesses that a move to indiscriminate mass exploitation is likely, given how low the complexity is. Public scanning data and honeypot reports over the coming days will show whether that happens, and whether ransomware crews pick it up.

Two other signals are worth tracking. GitLab publishes the underlying issue for each security fix 90 days after the patch, which will add detail once that window closes. And CISA may update the KEV entry if ransomware use is confirmed.

For teams running GitLab inside a software supply chain, the downstream question is bigger than the server. What could an attacker do with a stolen pipeline token before you rotated it?