603,475 Grafana and 77,968 Kibana Instances: Measuring the Observability Layer's Public Surface
Observability platforms sit in an unusual position. They are not production services, but they hold the credentials, query results and topology data that describe production. Grafana, Kibana and Prometheus are common in that role, and all three can be reached from the public internet.
ZoomEye data collected on 20 September 2026 shows how much of that layer is visible.
| Query | Exact count |
|---|---|
app:"Grafana" |
603,475 |
app:"Kibana" |
77,968 |
app:"Prometheus" |
248 |
app:"Zabbix" |
150 |
app:"RabbitMQ" |
227 |
app:"Kafka" |
165 |
app:"OpenSearch" |
571 |
Why the two large numbers need a caveat
The Grafana and Kibana counts are large enough that they should be read as fingerprint match counts rather than counts of live, reachable dashboards. Grafana and Kibana are both widely embedded and widely referenced, and a fingerprint can match assets, headers or pages associated with the product beyond a running instance.
That does not make the numbers useless. It makes them a starting point for a narrower query. Combining the application filter with a network filter, or with a port filter, produces a result set that can be attributed to a specific environment. The global count establishes that the product surface is large; the scoped query establishes whether any of it is yours.
What the smaller counts describe
Prometheus, Zabbix, RabbitMQ, Kafka and OpenSearch return counts in the hundreds, which makes them easier to reason about.
Prometheus is a metrics store and query engine. An exposed Prometheus endpoint often has no authentication by default, which makes it a direct information disclosure path. The count of 248 reachable services is small enough for an operator to check against their own inventory.
Zabbix is a monitoring platform with a web interface and an agent protocol. An exposed Zabbix frontend is an authentication surface, and the count of 150 describes how many answer publicly.
RabbitMQ and Kafka are messaging systems. Their counts of 227 and 165 describe brokers that answer from a public address. A message broker carries the data that applications exchange, and access to it is often equivalent to access to those applications.
OpenSearch is a search and analytics engine derived from Elasticsearch. The count of 571 describes reachable services, and an exposed search engine is a data exposure path in the same way a database is.
Why observability is a credential problem
A dashboard is only as sensitive as the data sources behind it. Grafana and Kibana connect to databases, log stores and metrics systems using stored credentials. An attacker who reaches a dashboard with weak or default authentication inherits those connections.
Metrics and logs also describe the environment. A Prometheus instance reveals service names, host names, versions and request patterns. A log store reveals error messages that frequently contain tokens, internal URLs and stack traces. This is reconnaissance that does not require exploiting a vulnerability.
Messaging systems sit between the observability layer and production. A broker that is reachable and unauthenticated gives an attacker the ability to read or inject messages, which is a path to the applications on both ends.
What to do with the measurement
Scope the queries to your own address space and treat the result as an inventory task. For each match, decide whether the service should be reachable from outside the expected network. Dashboards, metrics endpoints and message brokers generally should not be.
Where a service must be reachable, check the authentication configuration. Prometheus and several metrics exporters ship without authentication by default, so the presence of a login page is not a safe assumption. Put the service behind a reverse proxy that enforces authentication, or restrict access by network policy.
Rotate the credentials the dashboard holds. If a dashboard was reachable, the data source credentials it stored should be treated as exposed.
Re-run the queries after remediation to confirm the change. A service that stops appearing in a scoped result is a verified improvement.
Limitations
These counts describe fingerprint matches, not confirmed vulnerable or unauthenticated instances. The Grafana and Kibana figures in particular should be treated as match counts. Version detection and direct inspection are required before any host is classified as misconfigured. All figures are a snapshot from 20 September 2026.
References
- ZoomEye queries
app:"Grafana"(603,475),app:"Kibana"(77,968),app:"OpenSearch"(571),app:"Prometheus"(248),app:"RabbitMQ"(227),app:"Kafka"(165) andapp:"Zabbix"(150), collected 20 September 2026. - Grafana, Kibana, Prometheus, Zabbix, RabbitMQ, Kafka and OpenSearch product documentation for service roles and default authentication behaviour.
Top comments (1)
The scary part of an exposed Grafana or Kibana is not just the dashboards, it is that logs are often the only record of what happened, and an open instance means someone may have read or changed that record. After a breach, can the team still prove their logs were not edited? An append-only copy shipped somewhere the dashboard cannot touch is the cheapest fix I know. Did your scan see how many of these instances also expose write or admin APIs, not just read access?
iin1005h22