Scan counts 1.38M services on Kafka default port 9092, only 9,112 fingerprint as Kafka

A measurement exercise documented on dev.to illustrates how differently two common scanning queries describe Apache Kafka's footprint on the public internet. Using the ZoomEye search engine on 23 September 2026, the author ran a fingerprint query for assets tagged app="Kafka", which returned 9,112 matches, and a query for services on port="9092", the broker's default client port, which returned 1,377,501.

Two numbers, two populations

The figures answer different questions. A fingerprint query counts assets whose externally visible characteristics match the product; a port query counts every listener on a port, whatever that service happens to be. According to the dev.to post, the gap between the two is wide enough that the numbers should not be merged or treated as interchangeable.

The fingerprint result is the more conservative claim about Kafka specifically. Fingerprinting depends on what a broker reveals to an unauthenticated client, and hardened deployments reveal less, so the post treats 9,112 as a lower bound rather than a total.

The port number is the looser measure. Port 9092 is registered to Kafka, but the count includes services that are not Kafka at all, and it misses brokers configured to listen on other ports. The post reads it as the size of the listening population on that port, not as a Kafka deployment census.

What a reachable broker gives up

A broker reachable on its client port responds to protocol requests. Where authentication is not enforced, an outside client can enumerate topics, read the metadata that describes the cluster, and consume from streams that the applications writing to them consider private. The post cautions that event streams often carry more than intended: identifiers that can be joined against other datasets, internal service names, personal data embedded in payloads for convenience, and credentials passed along as configuration messages during deployment.

Kafka separates the listener used for client traffic from the controller listener that brokers use to coordinate cluster state. Exposing that coordination interface, or running a broker whose authorization model was never configured, creates conditions in which an unauthenticated client can both read data and alter cluster behaviour, including deleting topics or changing configuration, because the cluster effectively treats it as an administrator.

What the counts cannot tell you

Neither figure says anything about authentication or authorization setup. A cluster with mutual TLS and enforced ACLs looks identical from the outside to a cluster with neither. Neither number reflects topic inventory or message content, since the sensitivity of a broker is set by the applications that produce to it and no external measurement observes that. And neither measures exploitation: the counts describe reachability on the client port and nothing more.

The checks the post recommends

The review steps that follow from the measurements are network-first. Confirm that broker client ports are reachable only from the applications that produce and consume, using network controls rather than relying on client credentials. Make sure the internal listener used for broker and controller coordination is not reachable from any untrusted network, since it was not designed to face one. Enforce authentication and authorization at the broker, and treat an unauthenticated client as an administrator-equivalent exposure. Review what event payloads carry, because a broker aggregates data from many producers and one producer's poor payload hygiene can define the sensitivity of the whole stream. Finally, enable audit logging on the broker so topic access and administrative operations are recorded, since a reachable broker with no logging cannot be investigated after the fact. The post also points defenders to CISA's Known Exploited Vulnerabilities Catalog as a general reference.

Why it matters

The exercise is not a claim that nearly 1.4 million Kafka clusters are insecure; it is chiefly a lesson in reading scan data correctly. Product identification understates the reachable population, while port enumeration overstates the product population. A defender acting on the fingerprint figure alone may underestimate how much is actually listening, while one acting on the port figure alone may attribute unrelated services to Kafka. The practical upside is that the primary remediation, restricting broker ports at the network layer, is a configuration change rather than a code change, which makes it cheap for any organisation running Kafka to prioritise.