GitLab's CVE-2026-110264 affects every self-managed version from 7.0 onward, with fixes in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The natural next question is how many of those instances face the internet. That question has a defensible answer and several indefensible ones, and the difference lies in which ZoomEye field you trust.
A note on this article's evidence base: ZoomEye queries for this piece could not be executed because the API returned HTTP 502 during the research window. No counts are reported here. What follows is the query design, the field semantics behind it, and the interpretation rules that would apply once data is available. Presenting invented numbers as measurements would defeat the purpose.

Three fields, three different populations

title="GitLab" matches the HTML title of an HTTP response. It finds sign-in pages, and it also finds blog posts about GitLab, CI dashboards embedded in unrelated applications, and any page whose title happens to contain the string.
app="GitLab" matches a ZoomEye application fingerprint. Fingerprints are derived from response characteristics the scanner recognises as belonging to the product, and they generally survive cosmetic page changes better than a title string, at the cost of being stricter about what they accept.
ssl="gitlab" matches certificate content. It finds instances where an administrator named the certificate after the product, which happens often enough to be useful and never happens in organisations that use a wildcard certificate from a shared domain.
These three queries describe overlapping but distinct populations. A count from one is not an estimate of another, and adding them together produces a number that describes nothing.

Building a layered query

A reasonable layered approach, in the syntax the official ZoomEye prompt documents:

app="GitLab"
title="GitLab" && port=443
ssl="gitlab" && port=443

Run each, then intersect mentally rather than arithmetically. Assets appearing in the app result are the strongest candidates. Assets in the title result but not in the app result are worth sampling individually, because a genuine instance with a customised login page may fail fingerprinting while remaining identifiable by its title.
The version question needs a separate answer. ZoomEye can sometimes expose version strings through HTTP header or body fields, but the mapping from a version string to a fixed or vulnerable build is not something the scan data guarantees. A GitLab instance that reports a version in a footer may be reporting a version the administrator typed into a custom theme, or a version cached from an earlier deployment.

Why 12 years of version history breaks naive counting

CVE-2026-110264 covers 7.0 through the fixed releases, which means an instance running anything from 2014 onward is a candidate. Old instances are disproportionately likely to be self-managed, exposed without a reverse proxy, and reachable directly by IP address rather than by a domain name.
That last property is measurable and rarely measured. A query restricted to assets with no resolved hostname, or with a certificate whose subject does not match the host, describes a slice of the population that domain-based inventory misses entirely. These are also the assets least likely to appear in an organisation's own asset register.

What the number would and would not mean

If the query returns 40,000 assets, that figure describes internet-visible GitLab signatures. It does not describe vulnerable instances, because fingerprinting cannot read the installed version reliably, and it does not describe exploitable instances, because CVE-2026-110264 requires conditions GitLab has not fully published.
What the figure is good for is proportion. Comparing the count against the number of GitLab instances in the organisation's own inventory answers a question that matters to risk committees: are there internet-reachable GitLab servers that nobody recorded? A mismatch between external observation and internal inventory is actionable in a way that neither number is alone.

Interpretation rules that prevent embarrassment

State the query, the collection date and the field used. A count without those three is unreproducible.
Do not compare a title count from this month against an app count from last quarter and describe the difference as growth or decline.
Do not present internet-wide counts as a count of affected deployments. Exposure and vulnerability are separate findings, and the second one requires reading a version from the asset.

References

  • ZoomEye official MCP search syntax reference (field semantics for app, title, ssl, port)

  • GitLab security release, 21 October 2026, for CVE-2026-110264 and the affected version ranges

  • NVD entries for CVE-2026-110264 and CVE-2026-97229