ZoomEye scan finds 62,236 exposed Argo CD instances but only 497 on documented port 8080

An internet-wide measurement published on dev.to has counted 62,236 Argo CD deployments reachable from the public internet — and found that only 497 of them, under one percent, respond on port 8080, the port the project's own getting-started guide uses. The queries were run against the ZoomEye search engine on 26 October 2026, according to the post, and they illustrate how far real-world deployment practice can drift from documented defaults.

What the scan measured

Four numbers carry the story. The product fingerprint matched 62,236 hosts, and a separate query for pages whose HTML title contains the product name returned exactly the same figure. A further 30,239 hosts matched on certificate content, 25,079 combined the fingerprint with HTTPS on port 443, and only 497 combined it with port 8080. For contrast, 55,159,209 hosts answer on 8080 in total.

The author notes that the identical fingerprint and title counts suggest the classification rule is effectively derived from the page title. That makes the measurement internally consistent but fragile: a future release that changes the title, or a deployment hidden behind a login proxy that rewrites it, would slip past the count. The number therefore describes hosts serving an Argo CD page rather than every host running the software.

Why the documented port is nearly empty

The post attributes the 497 figure to two routine deployment patterns. Most Argo CD installations are published through a Kubernetes ingress with TLS, so the port the in-cluster manifest listens on never reaches the internet — the outside world sees 443. Others run the server with TLS terminated at a load balancer, which also lands on 443. The 25,079 hosts answering on 443, roughly 40 percent of the total, fit that picture.

The remaining hosts — the gap between 25,079 and 62,236 — either answer on some other port or have no port data recorded in the index fields the queries touched.

The bare port figure explains why scanning by port fails in both directions. With 55 million hosts on 8080, dominated by application servers, development instances and appliances, an open 8080 says almost nothing about what runs behind it. And scanning 8080 specifically for Argo CD, the author calculates, would miss 99.2 percent of the actual population.

The exposure is more serious than a dashboard

Argo CD is not a passive viewer. According to the post, an instance holds credentials for every cluster it manages, and its UI lists repository URLs, target clusters and namespaces — effectively a map of the delivery pipeline — even on servers that refuse a login. Repository credentials, cluster bearer tokens and SSO client secrets sit in Kubernetes Secrets within the Argo CD namespace.

The default installation also derives an initial admin password from the server pod's name, and operators are instructed to retrieve and change it; a deployment that skipped that step is left with a guessable credential. Where SSO is not configured, the local admin account is the only gate and its permissions are unrestricted. An internet-facing instance in that state hands an attacker control of the cluster rather than a view into it.

Checking your own deployment

The post closes with a short checklist. Confirm the server sits behind an ingress with TLS and that 8080 is not directly reachable. Confirm the generated admin password was replaced, or that local login is disabled once SSO is configured. Review which clusters and repositories the UI discloses, since a reachable UI reveals the estate even when it rejects logins. Finally, scope the server's RBAC so that an authenticated account does not automatically hold cluster-admin.

Why it matters

The headline finding is a two-orders-of-magnitude mismatch between documentation and reality: any asset inventory, attack-surface map or vulnerability scan built on the documented port will count roughly 500 systems when roughly 62,000 exist. Finding internet-facing Argo CD requires product fingerprinting, not port scanning. The population count also matters in its own right, because each exposed instance concentrates cluster credentials, pipeline metadata and a privileged admin account behind a single login — a far larger blast radius than a monitoring tool with the same footprint.