GitLab CE/EE (CVE-2026-85706)

On Thursday 10 September 2026 GitLab shipped a critical patch release. By 06:00 UTC the next morning, according to watchTowr, attackers were already probing for the flaw it fixed. For organisations running their own GitLab, that left hours, not weeks, between the advisory and the first attempts.

What is CVE-2026-85706

GitLab describes it like this: under certain conditions, an unauthenticated user could read arbitrary files from the GitLab server, due to improper path confinement and missing authentication enforcement in the repository commits API. Two checks failed at once. The API did not verify who was asking, and it did not keep the requested path inside the place it belonged. Together that is a path traversal open to anyone who can reach the server.

GitLab scores it 10.0 under CVSS v3.1. As of 1 October 2026, NVD lists GitLab’s score and has not published one of its own. Affected are GitLab CE and EE from 18.7 up to the fixed versions. GitLab.com and GitLab Dedicated are patched, according to GitLab.

What the attackers did

watchTowr saw the first probes in its honeypot network from 06:00 UTC on 11 September 2026, and CISA added the flaw to its Known Exploited Vulnerabilities catalog that same day. In a follow-up shared with The Hacker News, watchTowr reported that attackers had moved from probing to successful exploitation: they dumped configuration files for secrets, along with the system’s SSH configuration. According to watchTowr, that combination can let an attacker extract passwords and, under the right conditions, log in to the host itself.

This was an n-day, not a zero-day: the patch came first, the attacks followed. The Dutch NCSC warned on 12 September that the flaw was being actively exploited and that public exploit code was available. The German BSI followed with a security notice on 14 September. As of 1 October 2026, no government or security vendor has publicly named the actors behind the attacks.

Why a file read weighs so heavily on GitLab

On an ordinary web server, reading a file gets you a file. A GitLab server holds the source code, the pipelines that build and deploy it, and the credentials those pipelines use. watchTowr puts it plainly: access to GitLab gives an attacker source code, CI/CD secrets, credentials and the ability to inject code into build pipelines, poisoning anything downstream. The NCSC warns that the stolen data can be used to reach source code, development environments and linked systems.

That makes this a supply chain risk as much as a file read. And as with CVE-2018-13379, the damage outlives the patch: a token or password read in September keeps working until somebody rotates it.

What to do now

• Upgrade self-managed GitLab to 19.3.2, 19.2.6 or 19.1.8, or to 19.0.9 or 18.11.12 on older branches. According to Rapid7 the patch releases include database migrations, so plan for downtime on single-node installations.
• If the instance was internet-facing and unpatched after 10 September 2026, assume files were read. Rotate the passwords and keys in GitLab’s configuration, the CI/CD variables and tokens your pipelines deploy with, and the host’s SSH credentials.
• Search your logs for POST requests to /api/v4/projects/{id}/repository/commits/ with file.path parameters, the pattern watchTowr recommends hunting for. Rapid7 advises looking for signs of compromise even after the update.
• Keep GitLab off the open internet unless there is a reason, check whether it needs public projects at all, and include it in the scope of your penetration test.