When the Fingerprint Returns Zero: A PaperCut Measurement That Shows What ZoomEye Totals Cannot Count

Opening

In the same measurement session that sized the NGINX fleet at 309 million services, two ZoomEye queries returned zero: app="PaperCut NG" and app="PaperCut MF", both on 19 September 2026. The adjacent query title="PaperCut" returned 1,251,396 services. A zero next to a 1.25-million title match is not a contradiction. It is a working demonstration of the difference between a product fingerprint that exists on a platform and one that does not - and why reading exposure requires knowing which one you are quoting.

Context and method

PaperCut NG and MF are print-management products that run predominantly on internal networks, exposed through web interfaces on ports 9191 and 9192. The product's 2023 flaw (CVE-2023-27350) was exploited at scale, which made PaperCut a standard entry in exposure dashboards. The three queries above were executed with sub_type=all against the ZoomEye v2 API, using the official field syntax. No facets were requested for the zero-result queries because an empty result set has no distribution to facet.

What the zero means

A zero result from a well-formed query has three possible readings, and they must be distinguished:

1. The fingerprint does not exist on the platform. The platform has no detection logic named PaperCut NG or PaperCut MF. This is the reading consistent with the data here: a 1.25 million title-match population alongside zero fingerprint matches indicates missing detection logic, not a missing fleet.
2. The fleet is genuinely absent from the observable space. For an internal-network product this is partially true but not literally: the 1.25 million title matches show that print-management interfaces do reach the observable internet in large numbers.
3. The query is malformed. This was ruled out by syntax validation against the official field list and by the non-zero results of adjacent queries in the same session. Distinguishing these matters because the failure mode is asymmetric. Publishing "PaperCut exposure is zero" based on reading 1 would mislead every downstream consumer of the number. Publishing a title-match count of 1,251,396 as "PaperCut exposure" would overcount by including any page mentioning PaperCut in its title.

Implications for exposure reporting

Three practices follow:

• Validate fingerprints before quoting them. A probe query with a known-large adjacent population (here, the title match) is the cheapest possible validation that a zero is a data fact and not a vocabulary gap.
• Record the query, not just the number. The pair (app="PaperCut NG", 0) and (title="PaperCut", 1,251,396) together tell a reader everything needed to interpret both numbers. Either alone invites misreading.
• For products without platform fingerprints, use observable proxies with stated definitions. Title matching, specific port plus service combinations, or certificate subjects each define a different, defensible population - as long as the definition travels with the number. For PaperCut operators specifically, the defensive question remains unchanged: print servers should not be internet-reachable, and the 2023 exploitation wave demonstrated what happens when they are. The measurement difficulty of seeing them from outside does not change the internal hardening requirement.

Limits

This session's queries do not establish that the fingerprints exist under different names or sub-type scopes. A future query after platform fingerprint updates could produce different totals. The methodological point stands regardless: zero is a result that must be explained, not a number that can be published alone.

References

• ZoomEye v2 API responses recorded 2026-09-19: app="PaperCut NG" (0), app="PaperCut MF" (0), title="PaperCut" (1,251,396 with country facet)
• ZoomEye official search syntax documentation for app and title fields
• CVE-2023-27350 exploitation history as documented in CISA KEV and vendor advisories