1,587,145 vs 1,341,669: What Two F5 Fingerprints Reveal About Exposure Counting
Search results are often quoted as if they were inventory. A quick pair of queries against the same product family shows why that habit is risky, and how to read the numbers correctly when the underlying data disagrees with itself.
The measurement
On 20 October 2026, between 22:32 and 22:37 UTC, ZoomEye was queried with sub_type="all" and a page size of one record. Two product-fingerprint queries returned different totals for what a casual reader would consider the same vendor:
| Query | Matched assets |
|---|---|
app="F5 BIG-IP" |
1,587,145 |
app="F5" |
1,341,669 |
app="Citrix NetScaler" |
239,739 |
app="NetScaler" |
117,407 |
title="NetScaler" |
72,257 |
title="Citrix" |
240,774 |
The broader vendor string returns fewer matches than the specific product string. That is not a data error to be dismissed; it is a property of fingerprint matching that anyone building an exposure metric needs to understand.
Why the narrower query can return more
Application fingerprints in internet-wide scanning are assigned per signature, not per vendor hierarchy. A signature that identifies a load balancer's administrative interface may be labelled with the specific product name. A different signature, matching a login page or a server header, may carry the vendor name alone. Nothing guarantees that the set matching the specific label is a subset of the set matching the generic one, because the two sets are produced by different detection rules rather than by a taxonomy.
In practice this means:
- Adding a vendor-level count to a product-level count double-counts assets that match both.
- Subtracting one from the other is meaningless, because neither set contains the other.
- A "total F5 exposure" figure derived from a single dork understates or overstates depending on which signatures the scanner applies.
The same pattern appears in the Citrix numbers. app="Citrix NetScaler" returns 239,739 assets while app="NetScaler" returns 117,407, and title-based matching for the product returns 72,257. Four queries, four defensible definitions, four different answers.
What this means for the CVE-2026-94127 question
The BIG-IP APM vulnerability is configuration-dependent: only virtual servers running APM as an OAuth authorization server are affected. No external scan can determine that. Even a perfect inventory of every BIG-IP asset would not identify the affected subset.
So the honest use of a 1.5 million figure is narrow. It establishes that the product family is widely deployed and observable, which tells an attacker where to aim and tells a defender that exposure management for this product class deserves attention. It says nothing about how many appliances run the vulnerable role.
A defender's useful question is different: how many of my BIG-IP virtual servers carry both an access policy and an OAuth authorization-server profile? That is answerable with tmsh and internal records, in minutes, and the answer is exact.
A better measurement pattern
If external data is part of a prioritization process, use it with three constraints.
Pick one definition and hold it. Record the exact dork, the sub_type, and the timestamp. A metric that changes definition between months is not a metric.
Compare like with like. A title-based count and an application-fingerprint count are measuring different detection methods. Comparing them is legitimate as a robustness check; summing them is not.
Report the uncertainty. "Between 72,000 and 240,000 observable NetScaler-related assets, depending on signature definition" is a more accurate sentence than a single number presented as fact.
That last point is where most exposure reporting fails. Precision in the digits creates an impression of precision in the measurement, and the measurement has a definitional range far wider than the rounding.
The workflow that does work
External observation pairs well with internal inventory when the comparison is structured:
- Query the specific product fingerprint, not the vendor name, and store the query exactly.
- Extract the asset list for a bounded scope — a specific country, ASN or organization.
- Diff that list against your known asset records to find hosts nobody has claimed.
- Resolve ownership for each unexplained host before drawing any security conclusion.
- Repeat on a schedule with the identical query so that change over time is meaningful.
Step 4 is the one that turns scan data into an actionable finding. An unowned asset answering on a public address is a governance problem first and a security problem second, and it is discoverable long before any CVE becomes relevant.
References
- F5, security advisory K000162605 for CVE-2026-94127.
- CISA, Known Exploited Vulnerabilities Catalog.
- ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
Top comments (0)