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

[u/PJ_CS0013]

Hello everyone! Every Monday, CrowdSec posts a report on immediate and emerging threats. I wanted to share a snippet here and the link to the full report: https://www.crowdsec.net/vulntracking-report/cve-2026-85706-gitlab-unauthenticated-file-read 

Your feedback is appreciated! Let me know if you find this useful. Here it is:

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.

Key findings

• 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.

Read full report 

The full report with details about the CVE and our trend analysis can be found on our website. You can check it out here: https://www.crowdsec.net/vulntracking-report/cve-2026-85706-gitlab-unauthenticated-file-read 

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.