ZoomEye scan finds 810,266 internet-exposed Apache Solr instances

What the scan found

A post published on dev.to on 20 October 2026 describes a point-in-time census of Apache Solr on the public internet, carried out through the ZoomEye search engine on 26 September 2026 (UTC). Three queries produced three very different numbers:

• A fingerprint query for app="Apache Solr" matched 810,266 hosts.
• A title query for title="Solr" matched 73,029 hosts.
• A query for port=8983 matched 1,319,525 hosts.

The fingerprint result is the headline. Solr is an open-source search platform whose administrative API sits alongside its query endpoints, covering core administration, configuration upload and, in some configurations, remote streaming of data. According to the dev.to post, an instance that answers to the open internet is therefore a data-exposure risk and, depending on setup, a code-execution risk at the same time — and the project's advisory history includes vulnerabilities that were exploited in the wild.

Why the fingerprint count dwarfs the title count

The two detection methods disagree by a factor of eleven, and in the direction opposite to what a casual observer would expect: the fingerprint found far more hosts than the title search. The explanation offered in the post is that Solr's administrative interface often does not render a page title identifying the product, because deployments commonly put it behind a proxy or serve it under a custom path. The application fingerprint, by contrast, recognises the response structure the service itself produces, which survives changes at the presentation layer. The practical reading is that for Solr, fingerprint matches are the dependable count, while title matches should be treated as a floor.

The port figure is not a product census

The query for port 8983 returned the largest number, roughly 1.3 million, but the post cautions that it counts every service answering on that port rather than Solr installations. Whatever the port's original association with the software, it now carries enough unrelated traffic that it cannot stand in for an inventory of deployments.

What the counts do not establish

These are point-in-time matches from a single day. They say nothing about which Solr version any matched host runs, whether authentication is switched on, or what the underlying indexes contain. A fingerprint match does not show that a host is vulnerable to a specific flaw — only that a Solr-shaped service responded.

What operators should check

The post sets out four verification points for anyone running the software:

• Authentication. The administrative API should never be reachable without credentials. The project ships authentication and authorisation plugins, and turning one on is standard practice rather than optional hardening.
• Network placement. For internal deployments, keep the admin endpoint on an internal network or behind a proxy that enforces access rules, instead of on the same listener that serves queries to the outside.
• Version state. Because security information is published alongside each release, the operative question for any measured host is which version it is running — something a count cannot answer.
• Query-side access control. A search endpoint that returns documents drawn from sensitive sources is a disclosure path in its own right, even when the admin interface is locked down.

Why it matters

Roughly 810,000 Solr services answering on the public internet is a large standing attack surface for software with a track record of exploited advisories, even allowing that many of those instances may be authenticated, patched or both. The finding also carries a methodological lesson: discovery that relies on page titles undercounts Solr by about an order of magnitude, so organisations whose asset inventories are built from banners may simply not know they have exposed deployments. The follow-up work for defenders is version identification and authentication checks on whatever the fingerprint finds.