Building an Exposure Baseline: A Repeatable ZoomEye Method for Vulnerability Response

Exposure measurement is most useful when it is done before it is needed. An organization that runs its first internet-measurement query during an incident spends the first hours of that incident learning how to use the tool.

This article describes a repeatable method, using counts collected on 2026-09-22 across a set of products that appeared in September 2026 vulnerability reporting.

A baseline measurement set

All counts were collected through the ZoomEye SDK with sub_type="all" and a page size of one. Each query was run against a specific product fingerprint rather than a vendor name.

What a baseline like this is for

The purpose is not to produce a risk score. It is to establish, in advance, three facts that are needed during an incident.

First, which query represents each product. The baseline records the exact fingerprint string that produces a meaningful result. When a vulnerability is disclosed, the analyst does not have to guess whether app="SonicWall" or app="SonicWall SMA1000" is the right query; the baseline already answers that, and it also records that the two differ by five orders of magnitude.

Second, the order of magnitude for each product. Knowing that Kestra sits in the low hundreds and that RouterOS sits in the millions is useful context. A small population does not mean low risk, as the Kestra command injection demonstrates, but it does mean the population is specialized and that an organization running it is more likely to be identifiable.

Third, which products cannot be measured this way. The baseline should record negative results as well as positive ones. Framework-level components such as Starlette return no fingerprint, and that absence is a finding: it tells the organization that for that dependency, the inventory has to come from a software bill of materials rather than from an internet scan.

The method

1. Enumerate the products the organization actually runs. Start from the asset inventory, not from the vulnerability news. A baseline built from a news cycle will miss everything the organization uses that is not currently in the headlines.
2. For each product, test candidate fingerprint strings. Run the short and long forms, and test a deliberately wrong query such as the bare vendor name to confirm that a near-zero result means the fingerprint does not exist rather than that the product is rare.
3. Record the query, the scope parameter, the collection timestamp and the count together. A count without its query is not reproducible, and a count without its timestamp cannot be compared with a later measurement.
4. Note the deployment pattern where it is visible. Comparing a fingerprint with and without a port restriction, as the LiteLLM measurement shows, reveals whether the population is typically exposed directly or proxied.
5. Record the negative results explicitly. A product with no usable fingerprint is a product whose exposure cannot be tracked this way, which is itself an actionable finding.
6. Re-run the baseline on a schedule. Fingerprint coverage changes, and so does the population.

Using the baseline during an incident

When a vulnerability is disclosed, the baseline answers the scoping question in minutes rather than hours. The analyst looks up the affected product, uses the recorded query, and gets a comparable number to the baseline. The comparison is meaningful because both measurements used the same query and scope.

The baseline does not answer the question that matters most, which is how many of the organization's own instances are affected. That requires internal inventory and version data. What the baseline provides is the context in which that internal number can be interpreted: whether the product is common or specialized, whether the population is growing, and whether the organization's own deployment is typical.

Where ZoomEye fits

ZoomEye supports the fields needed for this method: app for product fingerprints, port and service for deployment pattern, is_ipv4 and is_ipv6 for address family scope, and vul.cve for CVE association coverage. Running the same query with different scope parameters is what makes the comparison meaningful, and recording those parameters alongside the count is what makes the baseline reproducible.

The platform's limitation is consistent across every measurement in this article: it sees what is network-visible, which excludes version information, internal-only deployments, and framework-level components. A baseline built on ZoomEye is a baseline of internet-visible exposure, and it should be labeled as such.

Limitations

Counts were collected on 2026-09-22 with sub_type="all" and pagesize=1, and they change as the platform rescans. Fingerprint coverage differs by product and is maintained by the platform. None of these queries establishes that a specific asset is vulnerable, and the counts do not represent the total install base of any product.

References

• ZoomEye official search syntax reference, covering the app, port, service, is_ipv4, is_ipv6 and vul.cve fields.
• CISA, Known Exploited Vulnerabilities Catalog, entries added September 2, 8, 11 and 12, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• iThome, "CISA warns of exploitation of known vulnerabilities in SonicWall, JFrog Artifactory, LiteLLM and other systems," September 3, 2026. https://www.ithome.com.tw/news/178657
• A5站长网, "Three JFrog Artifactory vulnerabilities exploited in the wild, added to CISA must-patch list," September 16, 2026. https://m.admin5.com/article/20260915/16702766.shtml