CVE-2026-85706: A CVSS 10 Path Traversal in GitLab's Commits API, Now in CISA's KEV Catalog
CVE-2026-85706, a path traversal flaw in GitLab's commits API, hit CVSS 10.0 and CISA's KEV catalog within a day. But there's one exposure condition that determines whether your instance is actually at risk.
CVE-2026-85706 is a path traversal vulnerability in the repository commits API of GitLab Community Edition and Enterprise Edition, and it carries the maximum possible CVSS score, 10.0. GitLab shipped a fix on September 10, 2026. Within about 20 hours, exposure management firm watchTow was already observing in-the-wild probing against it, and by September 11 CISA had added it to the Known Exploited Vulnerabilities catalog with a September 14 remediation deadline for federal agencies. A perfect score usually reads as "patch everything, everywhere, now," but one analyst's take on this flaw points to a narrower exposure condition worth checking before you triage it that way.
What the vulnerability is
The bug comes from improper path confinement combined with missing authentication enforcement in GitLab's repository commits API, tracked under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The API that serves commit data does not properly restrict the file paths it will read. An unauthenticated attacker can send a crafted request, using a file.path parameter with path traversal sequences against the /api/v4/projects/{id}/repository/commits/ endpoint, and get the server to return files it was never meant to expose.
No account, no authentication, and no user interaction are required, and GitLab rates the attack complexity as low. That combination, plus a scope change in the CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N), is what pushes the score to 10.0. Depending on what the GitLab process can read, exposure can include application settings, secrets, access tokens, SSH keys, and database credentials. The same release also patched a separate critical deserialization flaw (CVE-2026-87719, CVSS 9.9) in GitLab EE, but that one needs an authenticated user with Duo Chat access, a very different exposure profile from the one covered here.
Who is affected
CVE-2026-85706 affects self-managed GitLab CE and EE running 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab fixed it in 19.1.8, 19.2.6, and 19.3.2. GitLab.com already runs a patched version, and GitLab Dedicated customers don't need to act, so this is specifically a self-managed problem.
The question to answer for your own environment is not just whether you are on an affected version. watchTow's head of threat intelligence, Jake Knott, pointed out that exploitation has one real prerequisite: at least one public project has to exist on the instance. An internet-facing server with no public projects and default access controls sits in a meaningfully different risk position than one hosting public repositories, even though both show up identically as CVSS 10.0 in a feed. That does not remove the need to patch, but it changes how you order this against everything else in your queue.
The score tells you to act, the conditions tell you how fast
A CVSS 10.0 is rare, and it is tempting to read it as maximally bad everywhere. In one sense that is accurate: no privileges, no interaction, low complexity, and high confidentiality and integrity impact through the scope change. But the score alone does not tell you where to start when you are triaging more than one exposed instance with limited hands.
That is what the KEV listing and watchTow's probing report add on top of the number. CISA does not add a CVE to KEV because the math says 10.0, it adds one when there is confirmed or credible evidence of active exploitation, here probing that began within hours of the patch shipping. Combine an unauthenticated, single-request exploit with public disclosure and a research community that reverse engineers patches quickly, and the window from "patched but not yet applied" to "actively targeted" compresses to about a day. Knott's own read is that broader, indiscriminate exploitation is not far off. This one belongs at the top of your queue, and the public-project condition is what should decide which GitLab instance goes first.
Reading it on VulnTracker
On VulnTracker, CVE-2026-85706's page puts the pieces that matter for triage in one place: the CVSS 10.0 CRITICAL score, the Actively Exploited flag pulled from the CISA KEV catalog, and the SSVC markers (Active, Automatable, Total impact) that separate urgency from raw severity. The Affected Products panel lists GitLab against the 18.7, 19.2, and 19.3 lines, with a Track button for alerts if GitLab revises the advisory. The remediation panel keeps the CISA-driven deadline (September 14, 2026, under BOD 26-04) next to GitLab's own guidance to upgrade.
What to do
Upgrade self-managed GitLab CE or EE to 19.1.8, 19.2.6, or 19.3.2 (or later on your branch) immediately. GitLab has not published a workaround; restricting network access is a temporary compensating control if you cannot patch right away, not a substitute for it. The update includes database migrations, so single-node deployments see downtime during the upgrade, while multi-node deployments can use GitLab's zero-downtime process if configured correctly.
Because watchTow has already observed probing, treat internet-facing instances as possibly scanned, if not accessed. Review GitLab and reverse-proxy logs for POST requests to /api/v4/projects/{id}/repository/commits/ URIs with a file.path parameter containing traversal sequences, the pattern both watchTow and GitLab point to. If you find matches, rotate any credentials, tokens, or secrets that could have been reachable from the server's filesystem, and treat the instance as compromised until you confirm otherwise.
Takeaway
CVE-2026-85706 earns its maximum score honestly: unauthenticated, no interaction, low complexity, and already under active probing less than a day after the patch shipped. But even a 10.0 has conditions attached, in this case whether an instance hosts at least one public project, and that is what should set your patching order once the score alone puts everything in the same critical bucket.
If you run self-managed GitLab, sign up at vulntracker.io to track CVE-2026-85706 against your own stack and see whether your instances actually meet the exposure conditions that matter, not just the score.
References: GitLab security release, 19.3.2 / 19.2.6 / 19.1.8 · NVD, CVE-2026-85706 · The Hacker News: GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
Related reading
MikroTik RouterOS Under Active Attack (CVE-2026-86060): When There's No CVSS Score to Wait For
MikroTik RouterOS is being actively exploited, and CVE-2026-86060 is in the CISA KEV catalog. Here is the interesting part for anyone who prioritizes by severity score: at the time of writing, this CVE has no CVSS score. NVD has not analyzed it yet. If your triage process starts with "what's the CVSS," this one falls through the cracks while attackers are already using it. That gap is exactly what SSVC is built to close. What the vulnerability is CVE-2026-86060 is a privilege escalation flaw
Redis TLS Use-After-Free (CVE-2026-81934): A Case Study in Reading Severity Correctly
CVE-2026-81934 is a use-after-free in Redis that was first published as a CVSS 9.8 Critical, then reassessed down to High once the real exploitation conditions were weighed. It's a clean lesson in why the number on a CVE is a starting point, not the answer.
Metabase Pre-Auth SQL Injection (CVE-2026-72898): CVSS 10.0, Actively Exploited
CVE-2026-72898 is an unauthenticated SQL injection in Metabase, scored CVSS 10.0 and already in CISA KEV. One request to /api/session/reset_password gives an attacker admin access and the credentials for every connected database. If you run Metabase, patch today.