ZoomEye scan counts 45,644 Exchange servers answering on HTTP

A scan-based measurement published on dev.to has counted 45,644 Microsoft Exchange assets answering over HTTP on the public internet, out of a far larger pool of hosts fingerprinted as Exchange by the search engine ZoomEye. The queries were run on 1 October 2026 at 02:33 UTC, with global scope across all asset types, and the analysis is unusually careful about what the two numbers do and do not mean.

Two numbers, two populations

The broader query — a fingerprint match for Microsoft Exchange — returned 568,957 assets. The narrower one, which additionally required an observed HTTP service, returned 45,644. According to the dev.to post, the gap is not noise: a fingerprint match can pick up components identified through related evidence, while the HTTP-scoped result proves that a service was actually seen answering. Neither figure is a census of installed Exchange servers, the author warns, but the HTTP-scoped count is the closer approximation of externally reachable mail roles.

How this squares with earlier patching reports

The post situates its measurement against reporting from early September 2026, which estimated that roughly 22,000 Exchange servers were still running versions affected by CVE-2026-62911, with Germany identified as the highest-risk region in that dataset. The same reporting tracked 20 Exchange vulnerabilities in CISA's Known Exploited Vulnerabilities catalog since November 2021, 14 of them linked to ransomware.

The new count neither confirms nor contradicts the 22,000 figure, the dev.to author notes, because the queries measure different things. What it does establish is direction: Exchange is present on the public internet in quantities that make a version-based advisory expensive to close out manually, server by server.

Turning the scan into a checklist

The practical value, according to the analysis, comes from pointing the same queries at yourself rather than at the world. Its recommendations:

Scope the ZoomEye query to address ranges your organisation owns. For most teams the result should be a short, known list; an unexpected entry points to either an inherited server or a shadow deployment, and both are patch problems.

Distinguish client-facing roles from internal transport, because the count that matters for an external advisory is the reachable one.

Prioritise by build rather than service name — the Exchange version determines which advisories apply, and the exposure count only tells you where to look.

Track the trend over time. A count that rises between snapshots means something was published that should not have been.

What the data can and cannot say

ZoomEye records more than a service banner. Certificate subjects, HTTP headers and response features are the fields that let an operator separate a genuine internet-facing Exchange deployment from a residual fingerprint, and then compare that finding against the internal build inventory that a patching process depends on. The measurement answers a question internal records handle poorly — what is actually answering on the network from outside the organisation — but, as the author stresses, it cannot say whether any specific server is vulnerable, and should never be presented as if it could.

Why it matters

Mail servers are the one tier an organisation cannot hide behind a private network, because their entire purpose is to accept connections. That structural fact makes outside-in measurement of the mail tier unusually informative rather than merely routine. The 45,644 figure is best read not as a league table of insecure organisations but as a triage signal: a reminder that any Exchange footprint visible from the internet needs a current build inventory behind it, given how many Exchange flaws have already been weaponised and tied to ransomware. For defenders, the cheapest next step is the one the post suggests — run the same query against your own ranges and see what answers.