DEV Community

StarkMan
StarkMan

Posted on

9,112 Indexed Kafka Endpoints Against 1,377,501 Services on Port 9092

#exposuremanagement #datainfrastructuresecurity

9,112 Indexed Kafka Endpoints Against 1,377,501 Services on Port 9092

Message brokers sit in the middle of an application's data flow, carrying events between producers and consumers. Apache Kafka is the most widely deployed open-source broker for that role. Two measurements taken on 23 September 2026 describe its visible population from different angles: a query for app="Kafka" returned 9,112 matching assets, and a query for port="9092", the default Kafka broker port, returned 1,377,501.

Why two numbers

The queries describe different things. A fingerprint query counts assets whose externally visible characteristics match the product. A port query counts listening services on a port, regardless of product. The gap between 9,112 and 1,377,501 is wide enough that the two figures should not be combined or treated as substitutes for each other.
The fingerprint count is the more conservative statement about Kafka specifically. Fingerprints depend on what a broker reveals to an unauthenticated client, and hardened deployments reveal less, so the fingerprint figure is best treated as a lower bound.
The port count says more about the port. Port 9092 is registered to Kafka, and the figure includes services that are not Kafka, along with brokers configured to use other ports that the query does not reach. It should be read as the size of the listening population on that port, not as a Kafka deployment count.

What a broker exposes when it is reachable

A Kafka broker reachable on its client port answers protocol requests. Where authentication is not enforced, a client can list topics, read the metadata that describes the cluster, and consume from topics that other applications believe are private. Event streams frequently carry more than they seem to contain: identifiers that can be joined against other datasets, internal service names, personal data included in an event payload for convenience, and credentials passed as configuration messages during deployment.
Kafka's own configuration separates the listener used for client traffic from the controller listener that brokers use to coordinate cluster state. Exposing the controller interface, or exposing a broker with an authorization model that was never configured, creates the conditions where an unauthenticated client can both read data and affect cluster behaviour. Topic deletion and configuration changes are within reach of a client the cluster treats as an administrator.

What these numbers support

Together the figures support a distinction worth keeping: product identification understates the reachable population, and port enumeration overstates the product population. A defender who uses only the fingerprint figure may underestimate how much is listening. A defender who uses only the port figure may attribute unrelated services to Kafka.
The measurements also support a prioritisation argument for self-directed queries. An organisation running Kafka should determine whether its broker ports are reachable from outside its application networks, because the remediation is a network control rather than a code change and its cost is low.

What these numbers cannot support

Neither figure indicates authentication or authorization configuration. A cluster with mutual TLS and ACLs enforced and a cluster with neither look identical from outside.
Neither indicates topic inventory or message content. Data classification for a broker is a property of the applications that produce to it, and no external measurement observes it.
Neither measures exploitation. The counts describe accessibility on the client port and nothing more.

Review steps that follow

  1. Confirm that broker client ports are reachable only from the applications that produce and consume, using network controls rather than client credentials.
  2. Confirm that the internal coordination listener for brokers and controllers is not reachable from any untrusted network, since it was not designed to face one.
  3. Enforce authentication and authorization at the broker, and treat an unauthenticated client as an administrator-equivalent exposure.
  4. Review what event payloads carry. A broker aggregates data from many producers, and payload hygiene in one producer determines the sensitivity of the whole stream.
  5. Enable audit logging on the broker so that topic access and administrative operations are recorded, since a reachable broker with no logging cannot be investigated after the fact.

References

Top comments (0)