Code Hosting and CI on the Open Internet: Reading the GitLab and Jenkins Numbers

Source control and build infrastructure sit at the centre of software delivery, which makes their internet exposure worth measuring. Two ZoomEye queries run on 19 September 2026 produced a contrast that is instructive: the GitLab fingerprint returns a large population, while the Jenkins fingerprint returns almost nothing. The difference is a lesson in how fingerprint-based measurement behaves.

What was measured

The query app="GitLab" returned 1,262,273 matches in the IPv4 device dataset and 52,074 matches in the web dataset. The query app="Jenkins" returned 0 matches in the IPv4 device dataset and 3 matches in the web dataset. All four queries were executed on 19 September 2026.
The GitLab figures are large and the Jenkins figures are near zero. Taken at face value that would suggest GitLab is widely exposed and Jenkins is not, which does not match the operational reality that Jenkins controllers are a common target and a common finding in internal scans.

Why the two numbers diverge

The divergence is about fingerprintability, not about deployment. GitLab presents distinctive content on its login page, its application responses and its asset paths, which gives a fingerprinting engine reliable material to match. Jenkins, by contrast, is frequently deployed behind a reverse proxy, restricted to a VPN or internal network, or configured with custom paths and authentication in front of the controller. A default Jenkins install is recognisable; a hardened one is not, and hardened deployments are the ones that tend to be reachable at all.
This is the same pattern seen with the Cisco FMC measurement, where a management console fingerprint returned near zero. A low count from passive fingerprinting is evidence about the visibility of a service to that method, not evidence about how many instances exist or how many are exposed.

Why the GitLab number matters in context

The GitLab population is relevant because of CVE-2026-85706, an unauthenticated arbitrary file read in the repository commits API with a CVSS 3.1 score of 10.0, fixed on 10 September 2026 in 19.3.2, 19.2.6 and 19.1.8 and added to the CISA KEV catalog the next day.
The 1,262,273 IPv4 figure and the 52,074 web figure describe different observation types and are not additive. Neither is a count of vulnerable instances. A match means GitLab was observed at that address, not that the version is affected. The affected range covers self-managed Community Edition and Enterprise Edition from 18.7 up to but not including 19.1.8, the 19.2 branch below 19.2.6 and the 19.3 branch below 19.3.2, while GitLab.com and GitLab Dedicated are handled by the vendor.
What makes the population worth scoping is concentration. GitLab instances tend to sit in engineering organisations, hold credentials for downstream systems and connect to build pipelines, artifact repositories and cloud environments. A flaw that allows unauthenticated file reads reaches whatever the GitLab service process can access, which commonly includes configuration files, session and signing material, database and object storage credentials, runner registration material and deployment tokens.

Turning the measurement into an inventory

The useful workflow is reconciliation rather than counting. Use the fingerprint to build a list of what is externally visible, then compare it against internal asset records. Instances that appear externally but not internally are the ones most likely to sit outside the patch process. For each confirmed instance, check the version and determine whether the repository commits API is reachable directly or only through a proxy or access control layer.
ZoomEye's attack surface management capability supports this directly by taking an organisation's own asset clues and continuously discovering associated assets, which is what converts an external population estimate into a specific list of systems to verify.

What the measurement does not say

It does not say how many GitLab instances are vulnerable. It does not say which versions are running. It does not say whether any instance has been compromised. It does not say that Jenkins is rare, only that this fingerprint does not see it well. And it does not distinguish a deliberately published service from an accidentally exposed one.

The takeaway

A high fingerprint count and a low one can both be correct while describing visibility rather than deployment. GitLab is highly fingerprintable and its population is large; Jenkins is often hardened behind access controls and its fingerprint is thin. Neither number substitutes for an inventory, and both are more useful as a reconciliation input than as a finding.

References

• GitLab patch release 19.3.2, 19.2.6, 19.1.8, 10 September 2026.
• CISA Known Exploited Vulnerabilities catalog entry for CVE-2026-85706.
• ZoomEye queries app="GitLab" and app="Jenkins", IPv4 device and web datasets, collected 19 September 2026.