If your engineering team runs its own GitLab server instead of using GitLab.com, this is not a patch to schedule for next sprint.
An unauthenticated request that reads anything on the box
CVE-2026-85706 is a path traversal vulnerability in GitLab’s repository commits API. Because of improper path confinement and a missing authentication check, an attacker with no account and no credentials can send a single crafted request and read arbitrary files from the server, not just repository contents but configuration files, credentials, and CI/CD secrets sitting anywhere on the same filesystem. GitLab assigned it a CVSS score of 10.0, the maximum possible, and shipped fixes in versions 19.3.2, 19.2.6 and 19.1.8 on September 10. Every Community Edition and Enterprise Edition install from 18.7 up to those versions is affected.
One day from patch to attack traffic
The gap between disclosure and exploitation keeps shrinking, and this is one of the fastest examples yet. Security firm watchTowr recorded the first in-the-wild exploitation attempts against CVE-2026-85706 within a day of GitLab publishing its advisory, well before most self-managed instances had a realistic chance to patch. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11 and gave US federal agencies until September 14 to remediate, a three-day window that reflects how urgent the agency considers this.
Why this hits self-hosted teams hardest
GitLab.com itself is already patched, but that does not help the estimated 20,000-plus organisations running self-managed GitLab, many of them in Europe, where data residency and sovereignty requirements push teams toward on-premises or self-hosted source control in the first place. A GitLab server is not just a code repository. It typically holds CI/CD pipeline definitions, deployment credentials, and access tokens for everything downstream of it, which is exactly what a path traversal bug like this one is built to expose. A single unpatched instance can turn into a foothold for a much larger supply chain compromise.
What to check before end of day
If your organisation runs self-managed GitLab, confirm you are on 19.3.2, 19.2.6 or 19.1.8 or later, and treat any instance that was internet-facing and unpatched between September 10 and now as potentially compromised rather than merely at risk.
If you need help auditing your GitLab deployment, verifying whether you were exposed during that window, or rethinking how your CI/CD secrets are stored so one server compromise cannot cascade further, contact Excello Digital. We help European engineering teams close exactly this kind of gap before it becomes an incident.