GitLab's commits API returns arbitrary files to an unauthenticated caller at CVSS 10.0

An unauthenticated read makes reachability the whole control. The path is GitLab's repository commits API, and the flaw scores 10.0 under CVSS 3.1 ^[1]. According to the dev.to write-up, the practical ceiling of such a read is whatever the GitLab service process can open in that deployment, which commonly includes configuration files, session and signing material, database and object storage credentials, runner registration material and deployment tokens ^[5]. Upgrading closes the read, but anything read before the fix shipped on 10 September 2026 stays read ^[2].

Then the totals. The query app="GitLab", run against ZoomEye's current index on 19 September 2026, returned 1,262,273 matches in the IPv4 device dataset and 52,074 in the web dataset ^[6]. The first counts host and service observations carrying the GitLab fingerprint, the second counts website and domain records, and the post says the two are not additive ^[7]. The web figure is about 4.1 percent of the device figure ^[16]. The scan ran nine days after the patch ^[17].

For the larger number to say anything about CVE-2026-85706, three conditions would have to hold. The fingerprint would have to report a version, and the post says it does not carry version information reliably ^[8]. Every match would have to be a self-managed instance in an affected range, when the flaw hits self-managed Community and Enterprise Edition and the vendor handles GitLab.com and GitLab Dedicated ^[4]. And the commits API would have to answer at that address, which a fingerprint match does not establish, since the service may sit behind a proxy or an access control layer ^[9]. The post calls the figure a denominator for prioritisation ^[10].

The useful comparison is between the external view and internal asset records. Instances that appear in an external view and not in internal asset records are, per the same post, the ones that most often sit outside the patch process ^[11]. The post then recommends ZoomEye's asset and attack surface management capability, which takes an organisation's own asset clues and continuously discovers associated assets ^[12]. The scanner that produced the count is also the product proposed for the follow-up.

The per-instance work is sequential:

1. Inventory every self-managed instance, including disaster recovery nodes, and confirm the version on each ^[14]. 2. Upgrade anything in the affected ranges to 19.1.8, 19.2.6, 19.3.2 or later, and where an upgrade cannot be immediate, restrict public reachability as a stopgap ^[14]. 3. Enumerate what the GitLab service account can read, and rotate anything that was reachable and cannot be excluded from exposure ^[13].

Step three is the expensive one, and it is the step a patch does not do for you. GitLab instances tend to be concentrated in engineering organisations, frequently hold credentials for downstream systems, and are often wired into build pipelines, artifact repositories and cloud environments ^[15]. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 11 September 2026 ^[3][18]. The post itself carries no exploitation detail behind that listing.