Port-based exposure counts are the easiest number to produce and the hardest to interpret. Kafka makes the difficulty visible, because the gap between the port count and the product count is two orders of magnitude.
ZoomEye measurements collected on 28 October 2026 give port="9092" a count of 1,409,543. The same day, app="Kafka" returns 9,124, and title="Kafka" returns 24,135. Combining the two, app="Kafka" && port="9092", returns nothing at all.
That last figure is the one to sit with. It is not evidence that no Kafka broker listens on 9092. It is evidence that the fingerprint engine and the port observation do not co-occur in the indexed records, which is a statement about how ZoomEye classified those assets rather than about what they run.
What a port number can and cannot say
9092 is the port that Kafka client listeners conventionally use, and it appears throughout deployment examples. A large population of services reachable on that port is a real signal, but a weak one, because any TCP service can be instructed to listen there. A database, a proxy, a custom daemon, a honeypot: all can occupy 9092 and none of them will behave like a Kafka broker.
Kafka's own documentation treats listeners as configuration rather than as identity. The Apache Kafka documentation separates listener configuration from the security features layered on top of it, with distinct sections for SSL encryption, SASL authentication and authorization via ACLs. An operator can define several listeners on one broker, mapping each to a different security protocol, and can advertise an address to clients that differs from the interface it binds.
That flexibility is exactly why a port scan is a poor inventory tool for Kafka. Two brokers with the same port number can have entirely different security postures, and one broker can present several ports with different ones.
Why the product fingerprint is smaller than the port
The 9,124 figure comes from a fingerprint that looks for a Kafka-specific response. Brokers behind a proxy, brokers that require SASL before revealing anything, and brokers that expose only a TCP listener without any HTTP-adjacent surface will not match. The 24,135 title match is looser and picks up web-facing components whose page carries the product name, which includes management consoles and documentation deployments alongside brokers.
The consequence for an inventory argument is straightforward. Port counts answer "how many services are listening on a port that this product might use". Product fingerprints answer "how many assets identify as this product". Neither answers "how many are misconfigured", and the jump from 9,124 to 1,409,543 does not describe a security crisis in Kafka. It describes the cost of substituting a port convention for an identity check.
Using this in an exposure review
For an organisation running Kafka, the useful sequence is the reverse of the one a search engine offers. Start from the broker configuration: enumerate the listeners, note which security protocol each maps to, and confirm which addresses are advertised to clients outside the cluster. Then check whether any of those advertised endpoints resolve to a public address.
The ZoomEye query is a cross-check on that answer, not a substitute for it. A broker that appears under app="Kafka" is worth an immediate look at its authentication settings. A host that appears only under port="9092" is worth identifying, because if it is yours and it is not a broker, something else is listening where clients expect Kafka.
Two configuration questions decide most of the risk. First, is there a listener that accepts unauthenticated clients? Kafka permits a PLAINTEXT listener, and the documentation's security sections exist because that setting is common in development and dangerous in production. Second, is authorization enforced? SASL authenticates a client; ACLs decide what that client may do. A broker with authentication and no authorization rules accepts a valid principal and then honours whatever it asks for.
Where the numbers stop being useful
Broad port queries are popular because they produce large numbers, and large numbers make good headlines. In an internal risk register they are actively misleading, because they scale with the size of the internet rather than with the size of the problem. A count of 1.4 million services on one port tells you that a port is busy. It says nothing about whether the software behind any of those services is patched, authenticated or reachable by an attacker who wants it.
The narrower figures are the ones worth recording: 9,124 assets that identify as Kafka, 24,135 that carry the name in a title, and a joint query that returns nothing. That last result is a reminder that the two observations come from different parts of the same index and do not always intersect.
For a broker owner, the practical takeaway fits in one line: confirm the listener configuration and the ACL policy on each endpoint before trusting any external count, including a favourable one.
References
Apache Kafka documentation, security overview and listener configuration: https://kafka.apache.org/documentation/#security
ZoomEye query
port="9092", 2026-10-28: https://www.zoomeye.ai/searchResult?q=cG9ydD0iOTA5MiI%3DZoomEye query
app="Kafka", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJLYWZrYSI%3D
Measurement notes: all counts were collected on 28 October 2026 with the ZoomEye SDK through the AutoPR query operation. Counts describe indexed assets at that moment. They are not vulnerability counts, they do not identify vulnerable software versions, and they fluctuate as assets are added, removed or reclassified.