Dev.to Security ๐Ÿ” Cybersecurity ๐Ÿ‘ 0 ๐Ÿ“– 3 min read

603,475 Grafana and 77,968 Kibana Instances: Measuring the Observability Layer's Public Surface

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

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) and app:"Zabbix" (150), collected 20 September 2026.
  • Grafana, Kibana, Prometheus, Zabbix, RabbitMQ, Kafka and OpenSearch product documentation for service roles and default authentication behaviour.
๐Ÿ“ฐ Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.