ZoomEye scan counts 4.1 million hosts answering on Kubernetes API port 6443

A four-million-host count on one port

A measurement published on dev.to has put a number on how often the Kubernetes API server's default port answers from the public internet. According to the post, a ZoomEye query for port 6443 returned 4,138,087 matching hosts on 20 September 2026, the collection date.

The author is explicit about what that figure represents. It counts hosts that responded on the queried port at collection time. It does not count clusters, since one cluster can present multiple addresses and one address can front many clusters. It does not count vulnerable deployments, because no authentication test was run, and it does not count compromised ones, because no exploitation evidence was gathered.

Why 6443, and why the number is fuzzy

Port 6443 is a convention rather than a protocol guarantee. The dev.to article notes that managed control planes often front the API server on port 443 behind a load balancer, some distributions use 8443, and the legacy insecure port 8080 was removed from modern releases.

That makes port-based measurement error-prone in both directions. False positives arise because any service — proxies, internal APIs, test harnesses — can bind to 6443 without being Kubernetes. False negatives arise because a cluster exposed only on 443, or reachable solely through a VPN, bastion host, or private load balancer, will not appear in the scan at all. A TCP handshake or TLS banner proves a listener exists; it says nothing about whether the server demands client certificates, bearer tokens, or OIDC, or what anonymous requests are allowed to do. The post therefore frames its result as a lower-bound-style indicator of exposure on one conventional port, not a census of Kubernetes.

Why the API server is a high-value target

The kube-apiserver sits in front of the etcd datastore, the admission control chain, the authorization layer, and the machinery that issues credentials to every workload. The article identifies three properties that make it attractive to attackers: it is highly privileged by design, since a caller who can create workloads can often reach code execution on nodes, secrets, or cloud metadata endpoints; it is an ordinary HTTPS service that blends into normal web traffic; and it is frequently reachable by accident, because lab environments, CI runners, and self-hosted installs often inherit permissive security groups or bind to all interfaces during setup and are never tightened.

None of this is a flaw in Kubernetes itself. It is the reason exposure deserves careful measurement, and why reachability should not be conflated with compromise.

Exposure concentrates where compute does

According to the post, public exposure clusters around large cloud regions, hosting-heavy economies, and markets with dense container adoption. Security groups that allow all traffic on a management port turn private control planes into public ones, and templates reused across an organization produce correlated exposure. Self-managed clusters built for labs, training, or proofs of concept expose the raw port more often than managed offerings. Ephemeral infrastructure — CI systems, demo environments, short-lived test clusters — is frequently created with permissive networking and torn down late, or never. The author cautions that any geographic breakdown partly maps where servers are rented, not the security posture of any country or operator.

What an exposed endpoint actually enables

Impact depends entirely on authentication and authorization. With strong authentication and least-privilege RBAC, public reachability is a bounded problem: credential stuffing, unpatched API server bugs, misconfigured admission webhooks, or denial of service. If anonymous authentication is enabled and bound to a permissive role, the situation becomes severe — unauthenticated requests map to the system:anonymous user and system:unauthenticated group, and the cluster's RBAC configuration decides what those identities may do. A leaked credential, such as a service account token in a public repository or a kubeconfig baked into a container image, combined with public reachability, removes the attacker's need for network position entirely. In the worst case, sufficient API access allows enumerating secrets, creating privileged pods, mounting host filesystems, and pivoting into the surrounding cloud account.

Why it matters

The operational takeaway from the measurement is about the size of the search space: whatever fraction of those 4.1 million hosts are genuine Kubernetes API servers, the population is large enough that automated scanning of port 6443 is economically rational for attackers. For operators, the number is a prompt to verify whether the API server needs to be internet-reachable at all, to audit security groups and anonymous-authentication settings, and to treat the endpoint as an internet-facing TLS service that must be patched, monitored, and rate-limited.