GitLab has patched a flaw in its repository commits API that scored a perfect 10.0 on the CVSS severity scale — the highest a vulnerability can score. The bug, tracked as CVE-2026-85706, combines a missing authentication check with a path-traversal weakness, letting an attacker with no account and no password read arbitrary files off a vulnerable server with a single request, as long as the instance has at least one public project.
The flaw affects self-managed GitLab Community and Enterprise Edition installs — versions 18.7 up to 19.1.7, 19.2.0 up to 19.2.5, and 19.3.0 up to 19.3.1 — not GitLab's own SaaS service at gitlab.com. GitLab shipped fixed versions 19.1.8, 19.2.6 and 19.3.2 on 10 September 2026. Security firm watchTowr says it began seeing in-the-wild scanning for vulnerable servers the very next morning, and researchers note the exposed files can include server logs and configuration files that hold credentials, API keys and other secrets. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 11 September, confirming active exploitation and giving US federal agencies until today, 14 September, to patch.
What this means for your business
If your team runs its own GitLab server — on a company VPS or in-house, rather than using gitlab.com — treat this as a same-week patch, not a "next sprint" item: ask whoever manages that server (in-house developer or an outsourced provider) to confirm it's on 19.1.8, 19.2.6, 19.3.2, or newer today. Because the exposed files can include configuration secrets, also ask them to rotate any credentials, API tokens, or keys the server held if you can't confirm the patch was applied before the scanning started on 11 September. If your team only uses GitLab.com's hosted service, this particular flaw doesn't apply to you — but it's a good prompt to check who in your business actually owns that answer.