599 Million Apache and 313 Million nginx Matches: Where Counting Stops Being Useful

An exposure figure in the hundreds of millions is not actionable. It is too large to represent a decision, and it is large enough that its precision is an illusion. The interesting question is what these numbers can still be used for.

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:

The ordering is stable and unsurprising: two dominant web servers, then remote access, then mail, then the largest single CMS. What is worth examining is the diminishing utility of each successive magnitude.

The scale problem

At 599 million matches, a change of one percent is six million assets. No operational decision changes at that resolution. The number cannot distinguish between a healthy population and a compromised one, cannot identify which subset is unpatched, and cannot be verified by any human process.

It is a population estimate for a product class, and its only defensible use is as a denominator or a comparison against another measurement with identical definitions.

This is not a criticism of the measurement, which is accurate for what it claims. It is a limit on what a conclusion can be built from.

The magnitudes where decisions live

Useful thresholds are not universal, but the pattern holds:

• Above roughly 100 million. Population context only. Useful for statements such as "this product class is ubiquitous," and for nothing else.
• Between one and ten million. Still too large for individual action, but useful for relative comparisons between product classes and for detecting structural change, such as a major platform migration.
• Between ten thousand and one million. The range where a count can inform prioritization, because the population is small enough that a defender can reason about the composition.
• Below ten thousand. Small enough that both the population and its measurement artefact are relevant, and where a large percentage change may mean very little.

WordPress at 8.16 million sits in the second band. FortiMail at 3,932 and Zammad at 12,340, measured in the same session, sit in or near the fourth.

Why the small numbers are the harder ones

Counter-intuitively, the small counts in this series required more caution than the large ones. Zammad's 12,340 is meaningful because the product has a distinct fingerprint; but Jenkins at 3 and Kubernetes at 1 are the same kind of query producing values that describe detection coverage rather than deployment.

Large numbers are robust to fingerprint gaps because the product is common enough to be detected somewhere. Small numbers are not: a missing signature can remove ninety-nine percent of a population without any visible signal.

So the correct discipline is inverted from intuition. Trust large counts for what they are and distrust small counts until the signature is validated.

What an organization should actually extract

From a global measurement like this, an organization can extract three things:

1. A product-class denominator, to state relative position, for example "our CMS fleet is a negligible share of a very large population."
2. A definition to reuse for its own address space, so that its internal numbers are comparable over time.
3. A prompt to check whether any asset of that class on its own networks is answering from an address it should not.

The third is where the work is. The first two are paperwork that makes the third defensible.

The honest conclusion

Half a billion Apache matches does not tell anyone that half a billion servers are at risk. It tells them that a particular product signature is extremely widespread, which is consistent with Apache being the default web server of the internet for thirty years.

The value of publishing such numbers is calibration: they establish the scale against which smaller, decision-relevant figures should be read. They should not be cited as risk, and an article that presents them as risk is using the appearance of precision to avoid the work of interpretation.

References

• ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
• Apache HTTP Server, security reports.
• CISA, Known Exploited Vulnerabilities Catalog.