ZoomEye query finds 14,913 Kubernetes dashboards reachable on the public internet

A single title query returned 14,913 hits

A dev.to analysis published in late September describes a simple experiment on ZoomEye, a search engine for internet-connected systems: querying for the page title "Kubernetes Dashboard" returned 14,913 matches. The query, run with the engine's sub_type parameter set to all and collected on 2026-09-23, is a title-based fingerprint. It identifies assets whose HTML title matches the dashboard's title, which the post notes is a narrower and more specific signal than a generic product fingerprint.

That precision comes with caveats the author states explicitly. A title match does not reveal whether the instance requires a login, whether it is functional, or whether it still fronts a live cluster. Dashboards configured with a different title would not appear at all, and defunct assets can linger in results. The figure is therefore best read as a lower bound on dashboards presenting this specific title, not a census of every exposed Kubernetes management interface.

An exposed dashboard is not just another web app

The central argument of the analysis is that administrative interfaces carry a different risk profile per asset than ordinary web services. The Kubernetes Dashboard exists to operate a cluster: an authenticated user can enumerate workloads, read secrets and run commands inside containers. Publishing that interface to the internet removes the network boundary that would otherwise be the first control an attacker has to get past.

The post also anticipates the obvious objection. Tens of thousands of matches look small next to the hundreds of thousands of generic web services visible to scanners, and it would be a mistake to dismiss the number on those grounds. Per-asset consequence matters more than raw count here — one reachable dashboard with weak or disabled access control can be more damaging than thousands of exposed static sites.

How the exposure happens

Mostly by accident, according to the analysis. It points to three common paths: a dashboard installed for operator convenience and never restricted, a service type flipped from ClusterIP to LoadBalancer, or a misconfigured ingress rule. All three produce the same outcome — a management UI answering on a public address — without anyone consciously deciding to expose it.

What the analysis recommends

The post closes with a set of practical checks:

• Treat management interfaces as internal services by default, with any exception documented before it is exposed.
• Where remote access is genuinely needed, place the interface behind an authenticated proxy or a VPN rather than publishing it directly.
• Confirm the dashboard's own authentication is enabled and that an option to skip the login screen has not been left on.
• Monitor for new LoadBalancer services or ingress objects that expose administrative ports.
• Run ZoomEye against your own address space to verify that no management interface has quietly become reachable.

The author flags the limits of the exercise as well: title matching will miss dashboards that present a different title, and it may match assets that no longer work. The count is a prompt to verify your own deployments, not proof that 14,913 clusters are compromised.

Why it matters

The number puts a concrete figure on a well-known failure mode in cloud operations. Kubernetes has become default infrastructure for many organisations, and the dashboard is an optional, convenience component — which means each reachable instance represents a deliberate or accidental configuration choice that can be reversed. The scanning side is trivial: engines like ZoomEye index these interfaces continuously, so an unauthenticated dashboard at an unmemorable URL is not hidden, it is merely queued. The gap between "reachable" and "exploitable" is unknown from a title query alone, but the remediation is cheap and mechanical: keep management UIs off the public network, gate any genuine remote access behind a VPN or authenticated proxy, and verify that the dashboard's login has not been bypassed. For security teams, the actionable takeaway is the last one in the list — run the same query against your own ranges before someone else does.