DEV Community

StarkMan
StarkMan

Posted on

Kibana at 161,686 observed hosts: exposure of the interface that can read everything underneath it

#exposure #observability #attacksurface

Kibana at 161,686 observed hosts: exposure of the interface that can read everything underneath it

Kibana is the browser layer over Elasticsearch. It renders dashboards, provides a discovery interface for raw documents, and in many deployments holds the credentials used to query the cluster. Measuring it separately from the search engine behind it is worthwhile, because the two assets fail differently. One holds data, the other presents it in a form that requires no query language to exploit.

How the number was produced

A ZoomEye query for app="Kibana", run on 3 October 2026 with sub_type=all, page 1 and page size 1, returned 161,686 matches.

The interpretation rules are the same as for any measurement in this series. Page size does not limit the matched total, so the figure is a matched count rather than a sample. The sub_type=all scope aggregates IPv4, IPv6 and web results, which is broader than an IPv4-only query. Comparisons require an identical query field, identical sub_type and the same collection date.

What the fingerprint represents

Kibana serves its interface over HTTP, usually on port 5601, and includes a development console that can issue arbitrary Elasticsearch queries. Access control in a self-managed deployment depends on the security features of the connected cluster and on the reverse proxy in front of the interface. In smaller setups the interface has historically been reached through a proxy applying basic authentication, with the cluster bound to the local interface.

Two configuration facts change the risk profile more than version does. The first is whether anonymous access has been enabled deliberately, which is common during initial setup and sometimes left in place. The second is the privilege level of the service account Kibana uses to query the cluster, since dashboards and saved objects are stored in the same cluster the saved searches run against.

Interpretation and limits

A six-figure count for a monitoring interface is expected in environments where observability rollouts have been broad and per-team deployments common. It is also the kind of deployment where one team can stand up its own stack with default settings, which means the count captures both carefully operated platforms and side projects.

Being indexed carries no implication about authentication. A Kibana instance behind a proxy requiring login still answers a fingerprinting request. What the figure justifies is enumerating which interfaces exist and confirming the control in front of each one, rather than treating the presence of the fingerprint as a finding.

There is a further limitation specific to this asset class. Kibana is frequently deployed in the same network as the cluster it queries, and only the interface is exposed. The measurement shows the interface is reachable, not whether the cluster behind it is.

Practical next steps

Confirm which Kibana instances answer on public addresses and which are internal only, then verify the authentication layer in front of each reachable interface. Check whether anonymous access is enabled and, if it was enabled for a project that has finished, disable it. Review the cluster role granted to the Kibana service account and confirm it cannot write to indices it only needs to read. Audit saved objects for embedded credentials, since data source configuration in some plugins stores connection details in the object store. Confirm that the development console is either unavailable to non-administrative users or constrained by role-based access control.

Limitations

Counts include honeypots, staging deployments and shared hosting addresses, and a fingerprint can miss instances that alter their response headers or sit behind a rewriting proxy. The value reflects the collection moment.

References

Top comments (0)