72,548 in the US, 20,655 in Germany: Reading Geographic Distribution Without Over-Reading It
Country filters are among the most intuitive queries in an exposure dataset and among the easiest to misinterpret. A measurement of a single product across three countries, plus one query that failed, makes both the value and the limit concrete.
The measurements
On 20 October 2026, between 22:33 and 22:37 UTC, queries with sub_type="all" and a page size of one record returned:
| Query | Matched assets |
|---|---|
app="Citrix NetScaler" |
239,739 |
app="Citrix NetScaler" && country="US" |
72,548 |
app="Citrix NetScaler" && country="DE" |
20,655 |
app="Citrix NetScaler" && country="CN" |
14,157 |
The three country figures sum to 107,360, which is 45 percent of the global total. The remaining 55 percent is distributed across every other country.
What a country field means
Geolocation in an internet-wide dataset is normally derived from the IP address, using a commercial or open geolocation database. It describes where the address is registered rather than where the operator sits, and the two can differ for any organization using cloud infrastructure.
An asset hosted in a Frankfurt data centre belongs to whichever country the address block is registered to, regardless of the nationality of the organization running it. A multinational deploying in a single cloud region will concentrate in one country in this data while serving users everywhere.
That is why the distribution should be read as infrastructure placement rather than as an assessment of national security posture. The United States leads because a large share of global hosting capacity is registered there, which is a fact about the hosting market.
The comparison worth making
A more informative comparison is a product's country distribution against a baseline product's distribution measured in the same session.
In this round, app="WordPress" totalled 8,156,602 with 5,155,170 in the United States, a 63 percent concentration. Citrix NetScaler is 30 percent United States. The difference is meaningful in kind: a CMS is frequently hosted on commodity shared infrastructure concentrated in a few providers, while an ADC is deployed in organizational data centres distributed by where the organizations are.
That reading is an interpretation, not a measurement, and it should be held as a hypothesis rather than a conclusion. The measurement supports only the comparison of the two percentages.
The query that failed
One query in the same session did not return a number:
app="F5 BIG-IP" && is_honeypot="False"
It raised ValueError: internal error. That is recorded here as an error, not as a zero, and not as an absence of results.
The distinction matters more than it appears. An exposure workflow that treats a failed query as a zero produces a report claiming no matching assets, which then justifies closing a finding. A workflow that records the error produces a gap in coverage that someone can retry.
At least one query in any large session will fail. The handling of that failure determines whether the resulting report is usable.
A procedure for geographic analysis
- Measure the global total first, so the country figures have a denominator.
- Measure a baseline product in the same session, to separate product-specific patterns from general hosting geography.
- Report the country counts as percentages of the global total, not as absolute rankings.
- State the geolocation source limitation explicitly — address registration, not operator location.
- Record errors as errors, with the query string and the message, so a retry is possible.
Step five is the one that keeps the rest honest. A dataset with an unreported gap is worse than a dataset with a documented one, because the gap is invisible to whoever reads the conclusion.
References
- ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
- F5, security advisory K000162605.
- CISA, Known Exploited Vulnerabilities Catalog.
Top comments (0)