If your organization runs a self-hosted GitLab instance, stop what you are doing and check your version. A maximum-severity path traversal vulnerability, CVE-2026-85706 (CVSS 10.0), is being actively exploited in the wild, and the window to patch is closing fast.
GitLab disclosed the vulnerability on September 10, 2026. Within 24 hours, security firm watchTowr confirmed active probes across the internet targeting unpatched instances. By September 11, CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, giving federal agencies a patch deadline of September 14, 2026 — that is today.
What Is CVE-2026-85706?
The vulnerability lives in GitLab’s repository commits API. It is a combination of missing authentication enforcement and improper path confinement. An unauthenticated attacker can send a single crafted HTTP POST request to:
/api/v4/projects/{id}/repository/commits/
…containing a “file.path” parameter and read arbitrary files from the server. No login required. No user interaction. One request.
This means an attacker can dump SSH private keys, database credentials, deploy tokens, CI/CD environment variables, cloud provider API keys, and any other sensitive configuration data stored on the server. In short, they can own your GitLab instance and everything connected to it.
What Versions Are Affected?
All GitLab Community Edition (CE) and Enterprise Edition (EE) versions from 18.7 through:
– Before 19.1.8
– 19.2 before 19.2.6
– 19.3 before 19.3.2
GitLab fixed the issue in versions 19.3.2, 19.2.6, and 19.1.8. The same patch cycle also fixed CVE-2026-87719, an insecure deserialization flaw that could expose advanced search configuration and credentials — another good reason to upgrade instead of hunting for workarounds.
Exploitation Timeline
The speed here is the story. GitLab ships a patch on Thursday. By Friday, watchTowr reports active scanning. By Saturday, CISA adds it to the KEV. By Monday (today), the federal patch deadline arrives. Attackers do not wait for a convenient time to compromise your infrastructure.
This follows a pattern. CVE-2023-2825, another GitLab path traversal allowing arbitrary file reads, was also exploited within days of disclosure. CVE-2026-85706 is being exploited even faster.
What You Need to Do
1. Patch immediately. Upgrade to GitLab 19.3.2, 19.2.6, or 19.1.8 depending on your release track. Do not wait for a maintenance window — this is the maintenance window.
2. If you cannot patch right now, remove public access to your GitLab instance. Restrict it to your VPN or trusted IP ranges. This is a temporary measure, not a solution.
3. Hunt for exploitation in your logs. Look for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ that contain a “file.path” parameter. Any such request from an unauthenticated source is a red flag.
4. Rotate credentials. If your GitLab server stores SSH keys, deploy tokens, CI/CD variables, or cloud provider secrets — and it almost certainly does — assume they may be compromised. Audit access and rotate everything post-patch.
5. Check for signs of compromise before rotating. If you find evidence of successful exploitation, expand your response scope accordingly. Pull your cloud provider’s access logs and check for unusual API calls using GitLab-stored credentials.
GitLab is used by over 50% of the Fortune 100 and has more than 30 million registered users. That makes it a high-value target. CISA has tagged four GitLab CVEs as actively exploited since 2021. This is not a theoretical risk — it is happening right now.
Patch today. Check your logs. Rotate your secrets.