SURIQ
A single unauthenticated web request can read files straight off an unpatched GitLab server. That is the shape of CVE-2026-85706, the flaw at the top of the critical patch GitLab shipped on September 10, and the security firm watchTowr says attackers began scanning the internet for exposed, unpatched servers within a day of the disclosure. If you run GitLab on your own hardware, the window to patch ahead of them is measured in hours, not weeks.
The bug carries a maximum CVSS score of 10.0, the industry severity rating where nothing about it makes exploitation harder: no login, no user interaction, network-reachable. GitLab.com and GitLab Dedicated are already fixed by GitLab itself, so the exposure that matters here is self-managed: the servers your team runs. Upgrade on-premises installations to the fixed build for your track, then read on for what patching alone does not undo.
No login, any file
CVE-2026-85706 is a path traversal flaw, meaning the software can be tricked into stepping outside the directory it is supposed to stay in and reaching files elsewhere on disk. It lives in GitLab's repository commits API, the interface other tools use to query a project's commit history. Because that endpoint failed to confine the path it was handed and did not enforce authentication, an attacker who never logs in can walk it to arbitrary files. Anything the GitLab service account can read is in scope: configuration files, database secrets, access tokens, deploy keys, and SSH keys. It was reported through GitLab's HackerOne bug bounty program by a researcher using the handle s3ntago.
The flaw affects self-managed GitLab Community Edition and Enterprise Edition on every current track below the fixed builds, which are 19.1.8, 19.2.6, and 19.3.2, all released September 10. GitLab is urging every self-managed installation to upgrade to one of those immediately. If your instance is internet-facing, treat that as the definition of urgent.
Probing has started; confirmed exploitation has not
Be precise about the threat, because the difference changes how you triage. GitLab has not flagged CVE-2026-85706 as exploited in the wild. What watchTowr reported is that its telemetry is already seeing in-the-wild probes hunting for exposed, unpatched GitLab servers, a single HTTP request being enough to test for the flaw. That is scanning, not yet confirmed compromise. But an unauthenticated, single-request file read is exactly the class of bug that gets weaponised fastest: there is no access barrier to clear, and the immediate payoff, secrets, is the raw material for the next stage of an intrusion. Scanning today is the reconnaissance that precedes exploitation, so the honest read is that you are racing a countdown, not watching a theoretical risk.
Watch your GitLab access log for the fingerprint of that probing: requests to the commits API that try to smuggle a file path into the request.
# Rails production log on a self-managed GitLab server grep -E 'POST .*/api/v4/projects/[0-9]+/repository/commits/.*file\.path' \ /var/log/gitlab/gitlab-rails/production_json.log
A hit is not proof of a successful read on its own, but on an instance that was unpatched and reachable it is a strong signal to escalate to a full compromise review. If you find one, assume the secrets on that box may have been read and move to rotation.
The same release leaks credentials to a logged-in user
The critical patch fixes a second high-consequence flaw worth knowing about: CVE-2026-87719, rated CVSS 9.9. It is an insecure deserialization bug, the kind where an application rebuilds an object from attacker-influenced input and can be steered into doing something it should not. It sits in the serializer behind GraphQL subscriptions, GitLab's mechanism for pushing live query updates to a client. An authenticated user who has access to Duo Chat, GitLab's paid AI assistant, can craft a subscription argument that bypasses the intended serialization and performs a server-side object lookup, pulling back the Advanced Search instance configuration and its credentials. Advanced Search is the Elasticsearch or OpenSearch-backed search that Enterprise Edition can run, so the leaked material is a working set of credentials to a connected data store.
CVE-2026-87719 is narrower than its 9.9 suggests, because it requires an authenticated account that specifically has Duo Chat enabled, and it affects Enterprise Edition only. It is not the internet-facing emergency that CVE-2026-85706 is. But it lands in the same upgrade, so there is no reason to treat it separately. It is also not the first time GitLab's GraphQL surface has needed a patch: an earlier flaw let an unauthenticated attacker delete public projects through the same query interface.
One upgrade closes both, and fifteen more
These two are the headline entries in a release that fixed seventeen issues in total. The rest include several high-severity bugs that matter to a self-hosted operator: a pipeline execution policy that let developers reach protected continuous-integration and continuous-deployment (CI/CD) variables, a buffer overflow in the Advanced Search indexing path, and a cross-site scripting flaw in the Markdown table renderer, among lower-rated authorization and denial-of-service fixes. Moving to 19.1.8, 19.2.6, or 19.3.2 closes all of them at once, which is the argument for treating this as one decisive upgrade rather than a cherry-picked hotfix.
Patch, then rotate what could have leaked
For a self-managed GitLab operator, the work this week is short and ordered.
First, upgrade to the fixed build for your track now: 19.3.2, 19.2.6, or 19.1.8. This is the whole fix for CVE-2026-85706 and CVE-2026-87719.
Second, if you cannot patch in the next few hours, shrink the attack surface in the meantime. CVE-2026-85706 needs no login, so the single most effective stopgap is to get the GitLab web interface off the open internet: put it behind a VPN or an IP allowlist until you have upgraded. That does not fix the bug, it just takes you out of the scanners' reach.
Third, hunt the access log for the commits-API pattern above across the window your instance was both unpatched and reachable.
Fourth, and this is the step the patch does not do for you: if your server was internet-facing before you upgraded, treat the secrets it holds as potentially read. Rotate what an attacker could have pulled, database credentials, CI/CD variables, personal and project access tokens, deploy keys, and SSH keys, and invalidate active sessions. Patching stops the next read; it cannot un-leak a secret that was already exfiltrated. The detection here is not exotic, it is a log-pattern hunt on a single endpoint, which is exactly the kind of thing continuous monitoring should be watching on any internet-facing developer platform.