GitLab CVE-2026-85706 (CVSS 10.0) Path Traversal Actively Exploited; CISA KEV Sept 11

GitLab has shipped a fix for CVE-2026-85706, a critical path traversal flaw that carries the maximum CVSS score of 10.0, and for defenders the only thing that matters this week is getting patched. The bug sits in GitLab's repository commits API and allows an unauthenticated arbitrary-file read from a vulnerable server. GitLab published the patch release on September 10, 2026. One day later, on September 11, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added the CVE to its Known Exploited Vulnerabilities (KEV) catalog after exploitation was confirmed in the wild.

Attack-surface firm watchTowr said it observed probing of internet-facing GitLab servers, which is what moved this from a theoretical maximum-severity rating to an active-exploitation story. That combination, a perfect 10.0 score plus a KEV listing within 24 hours of the patch, is the clearest signal a security team can get that a vulnerability belongs at the top of the queue.

What GitLab Disclosed

GitLab published a critical patch release on September 10, 2026, addressing CVE-2026-85706. The company classified the flaw as a path traversal (CWE-22) in the repository commits API, present in both GitLab Community Edition (CE) and Enterprise Edition (EE). The impact GitLab described is an unauthenticated arbitrary-file read: an attacker who can reach the API does not need valid credentials to pull files off the underlying server.

Two facts make this one worse than the average GitLab advisory. First, the CVSS score is 10.0, the ceiling. A 10.0 means the flaw is network-reachable, requires no privileges and no user interaction, and has a severe confidentiality impact. Second, the affected component is an API endpoint that many GitLab operators deliberately expose, because reading commit data through the API is a normal, expected integration pattern for CI/CD systems, developer tooling, and internal dashboards. The thing that is broken is the thing organizations put on the internet on purpose.

Who is affected is broad by design. The flaw spans both editions, so this is not an enterprise-only or a community-only problem, and self-managed operators carry the most direct responsibility because they own the upgrade timing. GitLab.com and other vendor-hosted tenants are patched by the provider, but any organization running its own GitLab, whether the free CE build or a paid EE license, has to move itself. Because CE and EE share the affected repository commits API, a mixed estate cannot assume one edition is safe while it patches the other.

GitLab's own release channel is the authoritative place to confirm the fixed versions for your deployment, and the patched build should be treated as a same-day upgrade rather than a next-maintenance-window item. Coverage from Rapid7, The Register, and Dark Reading all converged on the same reading: patch now, because the window between disclosure and exploitation has already closed.

The Path-Traversal and Missing-Authentication Class

A path traversal flaw is one of the oldest and best-understood bug classes in web security, which is exactly why a fresh CVSS 10.0 example is worth a defender's attention. CWE-22 describes what happens when an application builds a file path from input it does not fully sanitize, letting a request escape the directory it was supposed to stay inside and reach files elsewhere on the host. The result here is arbitrary-file read: configuration files, secrets, tokens, and other server-side content that was never meant to leave the box.

What sharpens CVE-2026-85706 is the missing-authentication element. Many path-traversal bugs still require a logged-in session, which narrows who can reach them. This one does not. An unauthenticated request to the repository commits API is enough, so every exposed, unpatched instance is reachable by anyone who can route a packet to it. That is the difference between a flaw that threatens accounts and a flaw that threatens the server itself.

It also collapses the usual mitigations. Rate limiting, multi-factor authentication, and account lockout policies all assume the attacker needs an identity to act on. An unauthenticated read reaches past every one of them, which is why compensating controls buy far less time here than they would for a bug gated behind a login. The only reliable barriers are the patch and network reachability: a fixed build closes the flaw, and keeping the instance off the open internet limits who can reach it in the meantime. Neither substitutes for the other, and only the patch actually removes the vulnerability.

The CISA KEV Addition and Supply-Chain Risk

CISA added CVE-2026-85706 to the KEV catalog on September 11, 2026. The KEV catalog is a list of vulnerabilities with confirmed, real-world exploitation, and an entry is a statement of fact, not a forecast: someone is already using this. For US federal civilian agencies, a KEV listing starts a binding remediation clock under Binding Operational Directive 22-01. For everyone else, it is the strongest external prioritization signal available, and most mature vulnerability-management programs now treat KEV membership as an automatic escalation. You can confirm the entry directly in the CISA KEV catalog.

The supply-chain framing is where this stops being just another GitLab bug. GitLab is where source code, CI/CD pipelines, deployment credentials, and signing material live for a large share of software organizations. An arbitrary-file read against that system is not only a threat to GitLab; it is a threat to everything GitLab has keys to. Dark Reading and Infosecurity Magazine both framed the exposure this way, and it is the right frame. A file read that surfaces a CI token or a deployment secret can become a foothold in the downstream systems that GitLab automates.

My assessment, distinct from what the sources reported: the file-read impact is the headline, but the secrets reachable through that read are the real blast radius. Treat any exposed, unpatched instance as a credential-exposure event and not merely a patching task. That means rotating what the server could disclose, not just closing the hole. This is the same logic we applied to the earlier GitLab CVE-2026-19478 active-exploitation case, where watchTowr again drove the exploitation confirmation, and to the rapid disclosure-to-exploitation timeline that followed it.

What GitLab CE and EE Operators Should Verify

The defender action list is short and specific. It is ordered by what reduces risk fastest.

• Patch immediately. Upgrade every GitLab CE and EE instance to the September 10, 2026 patch release or later. Include forgotten and shadow instances: staging servers, acquired-company GitLab, and lab boxes that were never in the asset inventory. A single exposed unpatched host is enough.
• Find your exposure first. Before you finish patching, identify which instances are internet-facing. Those are the ones watchTowr says are already being probed, so they are the top of the queue. An instance behind a VPN or allowlist is still vulnerable but buys you time an exposed one does not.
• Audit repository commits API logs. Review access logs for the commits API for unusual, unauthenticated, or malformed path requests, especially any dated on or after September 10, 2026. This is where signs of an attempted or successful arbitrary-file read would appear.
• Monitor for arbitrary-file reads. Look for evidence that server-side files, particularly configuration files and secret stores, were accessed through the web tier. Unexpected reads of files outside the normal application working set are the signal that matters.
• Rotate what an exposed instance could have disclosed. If an instance was internet-facing and unpatched during the exposure window, treat CI/CD tokens, deployment keys, and stored secrets as potentially compromised and rotate them. Patching closes the door; it does not recall keys that may already have left.

For teams building this into a durable process rather than a one-off scramble, our complete guide to vulnerability management covers how KEV-driven prioritization, asset discovery, and exposure-based triage fit together so the next maximum-severity CVE lands in an existing workflow instead of a fire drill.

Open Questions

Several things are not yet established, and it is worth being explicit about them so the record stays honest.

No specific victim organizations have been named. Confirmed exploitation, per watchTowr, means probing of internet-facing servers has been observed; it does not, on the public record, amount to a named breach. No threat actor has been attributed to the activity, so this is not yet tied to a known group or campaign. And the number of compromised GitLab instances is unknown. Probing is not the same as compromise, and neither GitLab nor CISA has published a count of confirmed intrusions.

None of those gaps change the defender action. A CVSS 10.0, unauthenticated, actively exploited flaw in a system that holds source code and deployment secrets is a patch-today problem regardless of how the attribution and victim picture fills in. We will update this story as GitLab, CISA, or the research community publish more.

Primary documents:

• GitLab critical patch release (September 10, 2026)
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-85706 added September 11, 2026)
• Rapid7 analysis: CVE-2026-85706 exploited in the wild
• The Register: perfect-10 GitLab bug under attack days after patch