On 10 September 2026, GitLab shipped emergency patches for a path traversal flaw in the repository commits API that scores a perfect 10.0 on CVSS — the maximum possible severity. By 06:00 UTC the next morning, security researchers were already watching internet-wide scanning for it. CISA added it to its Known Exploited Vulnerabilities catalogue and gave US federal agencies until 14 September to patch. If you run a self-managed GitLab Community Edition or Enterprise Edition instance, this is not a bug to queue for your next maintenance window.
What CVE-2026-85706 actually does
The flaw, tracked as CVE-2026-85706, combines improper path confinement with missing authentication enforcement in GitLab's repository commits API. In practice, that means an attacker who has never logged in can send a single crafted HTTP request and read arbitrary files off the server — no account, no session, no exploit chain required. Researchers describe the trigger condition as almost trivially easy to meet: the instance only needs at least one public project to exist, which is true of a large share of self-hosted GitLab deployments by default.
What an attacker can pull off the server is the part that should worry you most: GitLab-specific configuration files, log files, stored credentials, secrets and system SSH configuration. On a CI/CD platform that most teams wire directly into their deployment pipelines and cloud accounts, that is not a read-only inconvenience — it is a plausible path to full compromise of everything GitLab has access to.
The affected versions
Reporting on the exact affected range varies slightly by source, but converges on GitLab CE and EE releases from 18.7 up to 19.1.7, 19.2 up to 19.2.5, and 19.3 up to 19.3.1. GitLab fixed it in 19.1.8, 19.2.6 and 19.3.2. If you manage your own GitLab instance rather than using GitLab.com's hosted service, check your version against that list today — not this sprint.
Why the timeline matters
The gap between patch and exploitation here was measured in hours, not weeks. GitLab published fixed versions on 10 September; by the following morning, researchers at watchTowr and elsewhere were already tracking internet-wide probing for the flaw. CISA's Known Exploited Vulnerabilities listing followed within a day, with a remediation deadline of 14 September for US federal civilian agencies — a short window even by KEV standards, and a reflection of how easy this flaw is to weaponise once the patch reveals what was broken.
That compression is now normal for maximum-severity, unauthenticated vulnerabilities in widely deployed software. The patch itself is effectively a map of the bug for anyone willing to diff it against the previous release, and attackers routinely have working exploits within a day of disclosure. Treating a CVSS-10 advisory as something to patch "this week" is no longer a safe assumption for internet-facing infrastructure.
What to actually do about it
If you self-host GitLab CE or EE: patch to 19.1.8, 19.2.6, 19.3.2 or later today, and confirm the version is actually applied, not just downloaded. Second, treat this as a possible-compromise event rather than a clean patch-and-move-on: review GitLab access logs for unauthenticated requests to the commits API around and after 10–11 September, and look for file paths that resemble traversal attempts. Third, given what the flaw exposes, rotate any secrets stored in GitLab CI/CD variables, deploy tokens and SSH configuration that could plausibly have been read, even if you find no direct evidence of exploitation — the cost of an unnecessary rotation is far lower than the cost of assuming you were safe based on absent logs. Fourth, if your GitLab instance sits behind a firewall or VPN with no public project, your exposure is meaningfully lower, but confirm that is actually true rather than assumed; a stale public project you forgot about is exactly the kind of gap this flaw needs.
If you use GitLab.com's hosted SaaS product rather than self-managed CE/EE, this specific advisory does not apply to you in the same way — GitLab is responsible for patching its own hosted infrastructure — but it is worth confirming with your GitLab admin which deployment model your team actually runs, since "we use GitLab" and "we self-host GitLab" carry very different obligations here.
The bottom line
CVE-2026-85706 is a maximum-severity, unauthenticated, one-request file-read bug in self-managed GitLab CE and EE, patched on 10 September and under active scanning within a day. If you run GitLab CE or EE yourself, patch to 19.1.8, 19.2.6 or 19.3.2 today, check your access logs for the days around the disclosure, and rotate any secrets the flaw could plausibly have exposed.