Download the latest Vulnerability & Exploitation Report

Download now

CrowdSec

VulnTracking
CVE-2026-85706 GitLab

GitLab Unauthenticated File Read (CVE-2026-85706): Upgrading Closes the Hole, Not What Already Leaked Through It

CVE-2026-85706 is a CVSS 10.0 unauthenticated file read in self-managed GitLab CE/EE 18.7 to 19.3.1. On an instance with a public project, anyone can read server files, including configuration and secrets. CrowdSec has traced 1,022 unique IP addresses sending matching requests since September 11, 2026. Upgrade today; if you were exposed, rotate secrets.

CVE-2026-85706

CVE-2026-85706 at a glance

  • Affected: Self-managed GitLab CE/EE 18.7 to 18.11.11, 19.0.0 to 19.0.8, 19.1.0 to 19.1.7, 19.2.0 to 19.2.5 and 19.3.0 to 19.3.1. GitLab.com and GitLab Dedicated are already patched.
  • Fixed in: 19.3.2, 19.2.6 and 19.1.8 (September 10, 2026); 19.0.9 and 18.11.12 (September 23, 2026). No fix for 18.7 to 18.10.
  • Vulnerability class: Path traversal with missing authentication in the repository API (CWE-22)
  • Severity: CVSS 3.1: 10.0 Critical (GitLab)
  • Authentication required: None. Per watchTowr, the observed attack path needs at least one public project on the instance.
  • Public exploit: Yes. A Nuclei template and proofs of concept (0xenesbayram, gitread) are public.
  • CISA KEV: Added September 11, 2026, in the catalog update released at 19:32 UTC (CISA kev-data); federal deadline September 14, 2026
  • CrowdSec detection rule live since: September 28, 2026
  • First exploitation attempt observed: September 11, 2026 at 23:30 UTC by CrowdSec, found retroactively in signals users had already shared once the rule shipped (explained below); September 11 from 06:00 UTC per watchTowr
  • Exploitation phase: Rapid Escalation (since September 30, 2026)
  • Observation window used here: signal counts from September 28 to October 4, 2026 (the last 7 full days). Daily and total unique IP addresses from September 11 to October 5, 2026, per the Live Exploit Tracker, including matches found retroactively. Source profile: the 959 addresses CrowdSec CTI links to the CVE over the 30 days to October 5.

Key findings

GitLab Unauthenticated File Read (CVE-2026-85706)
  • Probed the day after the patch: GitLab shipped fixes on September 10. On September 11, watchTowr saw probes from 06:00 UTC, CISA listed the flaw at 19:32 UTC, and CrowdSec’s earliest matching request, found by looking back once its rule shipped, came at 23:30 UTC.
  • Two addresses made most of the noise: Of 2,835 signals recorded between September 28 and October 4, one address in Lithuania sent 1,034 on October 1, and one in Latvia sent 782 on October 4. Together, 64% of the week.
  • Most sources are generalist scanners; a few are not: 648 of the 959 addresses in CrowdSec CTI are AWS servers in Dublin matching a median of 38 CVEs each. 114 matched nothing but CVE-2026-85706; 53 of those sit on Korean and Czech telecom networks.
  • One request, public tooling: A Nuclei template and public proofs of concept reduce the attack to one unauthenticated HTTP request. The 0xenesbayram proof of concept lists gitlab-secrets.json and gitlab.rb as targets.

What is GitLab, and who is exposed to CVE-2026-85706?

GitLab is where many companies keep their source code, run the pipelines that build and deploy their software, and store the credentials those pipelines need. Engineering and platform teams run it, often internet-facing so remote staff and contractors can reach it.

Why CVE-2026-85706 matters: gitlab-secrets.json holds the keys that encrypt CI/CD variables (cloud credentials, deploy tokens) and sign user sessions. gitlab.rb often holds database, LDAP, SMTP, and object-storage passwords. That is not theoretical: in 2020, William Bowling turned a GitLab file-read bug (CVE-2020-10977) into remote code execution by reading the secret_key_base signing key and using it to sign a malicious cookie.

On the Live Exploit Tracker, 71% of targeted organizations are in commerce, and 19% are small offices and home offices; 89% of the observed intent is classified as infrastructure takeover. By signal volume, targets sit in Germany (33%), Russia (19%), France (14%), Japan (14%), and Finland (12%); the Russian and Japanese shares come almost entirely from two one-day spikes. This describes where CrowdSec has visibility, not where GitLab is deployed.

How does CVE-2026-85706 work?

GitLab sits behind its own front-end component, Workhorse, which handles uploads and tells the Rails application where an uploaded file is stored through an internal file.path parameter. Workhorse matches upload routes on the raw URL; Rails decodes it first. Percent-encode one letter of the repository API path (%66iles for files), and Workhorse passes the request through untouched, so Rails reads whatever file.path the attacker supplied. The root cause: Rails trusted a parameter only Workhorse should ever set, and did not confine it to the repository.

The same releases fix CVE-2026-87719, a critical insecure deserialization flaw in GitLab EE’s GraphQL subscription serializer. Upgrading closes both.

What is the CrowdSec Network observing for CVE-2026-85706?

Between September 28 and October 4, 2026, the CrowdSec Network recorded 2,835 signals from machines reporting requests that match the CVE-2026-85706 exploitation pattern, detected by the CrowdSec scenario released on September 28, 2026. That averages 405 signals per day, peaking at 1,160 on October 1.

The activity is older than the rule. Machines in the CrowdSec Network share signals about the suspicious requests they receive, whether or not a rule for that specific CVE exists yet. When the CVE-2026-85706 rule was released on September 28, CrowdSec ran it over the signals users had already shared and found matching requests dating back to September 11 at 23:30 UTC, four hours after CISA’s KEV listing. That is why the Live Exploit Tracker’s daily count of unique addresses starts on September 11: 1 that day, 18 on September 12, 42 on September 13, then between 48 and 73 on most weekdays. The rule’s release does not show as a jump, because the requests were already arriving. In total, the tracker lists 1,022 unique IP addresses between September 11 and October 5, peaking at 94 on October 2.

By signal volume, sources come from Lithuania (37%), Latvia (28%), Ireland (14%), and South Korea (9%). Each of the first two is a single address flagged as malicious in CrowdSec CTI. The Lithuanian one also matched last week’s WordPress flaw, CVE-2026-87902; the Latvian one’s only other CVE on record is CVE-2025-30208, a file read in the Vite development server. Without them, daily volume sat between 65 and 225 signals.

By address count, the picture changes. Of the 959 addresses CrowdSec CTI links to CVE-2026-85706 over the 30 days to October 5, 648 are AWS servers in Dublin (eu-west-1), mostly aiming at French and German targets. They match a median of 38 CVEs each, and 553 also matched the Proxmox VE flaw from Week 37, the same Dublin pattern seen behind Langflow in Week 36. A broad scanning fleet that added GitLab to its list.

The part worth flagging is the small group that does nothing else: 114 addresses matched only CVE-2026-85706. 33 sit on Korean broadband providers (Korea Telecom, SK Broadband, LG HelloVision), 11 were first seen by CrowdSec on October 4, and 20 on Czech mobile and broadband carriers (O2, Vodafone, T-Mobile). Telecom networks, rather than rented servers, are consistent with residential proxies or compromised home and mobile devices. These are the sources a blocklist sees last.

What this data does not show

  • A matching request is an exploitation attempt. CrowdSec cannot confirm any of them succeeded, or that the target had the public project the attack needs.
  • 1,022 unique IP addresses is not 1,022 threat actors. One operator can rotate through hundreds of cloud addresses.
  • These counts come from traffic reaching machines participating in the CrowdSec Network: a sample, not a census.
  • The September 11 to 27 figures were found after the fact in signals users had already shared. A request no machine reported at the time is not in them, so the early weeks, when unpatched servers were most exposed, may be undercounted. Signal totals here cover only the last seven days; earlier days are counted in unique addresses.
  • The rule flags a file.path or file.size parameter sent to the GitLab API. It does not tell which file was requested.
  • Seven days is short, and two single-address spikes are not a trend.

What defenders get wrong about CVE-2026-85706

The first mistake is waiting for your branch. GitLab’s maintenance policy backports security fixes to the three latest releases. Teams on 18.11 and 19.0 got a fix on September 23, after twelve days of known exploitation; teams on 18.7 to 18.10 never will. Jumping versions may mean GitLab’s required upgrade stops, and the update includes database migrations that need downtime on single-node installations, per Rapid7. That cost is real. It is still smaller than losing what gitlab-secrets.json protects.

The second mistake is treating “patched” as “done”. A file read leaves nothing on the server but log lines, and upgrading does not make a stolen key useless. If an instance with a public project was reachable and unpatched after September 10, assume its secrets are out. Passwords in gitlab.rb, runner tokens, and the cloud credentials stored as CI/CD variables can be rotated today. The keys inside gitlab-secrets.json decrypt data already in the database, so changing them is a project, not a command. Plan it rather than skip it. The same goes for edge blocking: a virtual patch stops new requests, not a read that already happened.

How do you protect GitLab against CVE-2026-85706?

Patch. Upgrade GitLab to 19.3.2, 19.2.6, 19.1.8, 19.0.9, 18.11.12, or later (advisory). From 18.7 to 18.10, move to a supported release along GitLab’s upgrade path. Confirm with sudo gitlab-rake gitlab:env:info on Linux package installations, or on the Admin area dashboard. Until then, setting public projects to internal or private removes the precondition watchTowr describes: it narrows exposure; it does not fix the flaw.

Virtual patching with CrowdSec AppSec. The CrowdSec AppSec Component inspects HTTP requests before they reach GitLab and blocks those matching crowdsecurity/vpatch-CVE-2026-85706: a file.path or file.size parameter sent to /api/v4/, in the URL or the body. Only Workhorse sets those after the request has passed the remediation component, so legitimate uploads are unaffected. The rule keys on the parameter, not the encoding trick, so it also catches variants such as %63ommits.

Preemptive blocking. Subscribe to the Live Exploit Tracker page for CVE-2026-85706 or the CrowdSec Intelligence Blocklists to drop the addresses behind this activity. That covers the AWS fleet and the two high-volume addresses; it is weaker against telecom addresses first seen this week, hence the virtual patch. Query the observed sources in CrowdSec CTI.

Frequently asked questions about CVE-2026-85706

Is CVE-2026-85706 being exploited in the wild? Yes. watchTowr observed probes from 06:00 UTC on September 11, 2026; CISA added it to KEV at 19:32 UTC, and CrowdSec’s earliest matching request dates to 23:30 UTC that day. The CrowdSec Network recorded 2,835 matching signals between September 28 and October 4.

Which versions of GitLab are affected by CVE-2026-85706? Self-managed GitLab CE/EE from 18.7 up to 18.11.11, 19.0.8, 19.1.7, 19.2.5, and 19.3.1. The first fixed releases are 19.3.2, 19.2.6, 19.1.8, 19.0.9, and 18.11.12. Versions 18.7 to 18.10 have no fix.

Can I mitigate CVE-2026-85706 without upgrading? Partly. Removing public projects narrows the known attack path, and the CrowdSec virtual patch blocks the request pattern at the edge. The flaw stays until you upgrade, and neither undoes a read that already happened.

Related CrowdSec threat alerts

Written by Matthieu M., Data Team Lead, CrowdSec. Published October 5, 2026.

Sharing insights and taking swift action can collectively reduce the impact of these threats. This is your call to action for real-time threat intelligence and collaborative cybersecurity.

WRITTEN BY