5,623,921 MQTT Services: The Message Bus That Ships With the Building

MQTT is the protocol that makes cheap hardware useful. A sensor reports a temperature, a broker forwards it, a dashboard draws a line. The broker is the only component in that chain with an identity, and it is frequently the only component nobody configured.

Context and method

Counts from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations, and not a statement about authentication.

The service fingerprint reports 5,623,921 matches. Restricting to the conventional plaintext port drops that to 4,740,183, leaving 883,738 matches on other ports. That remainder deserves attention: a broker moved off 1883 for tidiness was not thereby secured, and the port-scoped query misses it completely.

The size gap is also a caution about scoping. Much of the useful signal in this index comes from knowing which filter was applied, and the difference between 5.6 million and 4.7 million is exactly the difference between saying MQTT is exposed and saying MQTT is exposed on the port you assumed.

Why the broker is the interesting part

MQTT has an authentication model whose defaults are permissive, because the protocol was written for constrained devices. Brokers ship with options for anonymous access and for accepting connections without TLS, and both are convenient during commissioning.

Once a client is connected, the broker's topic tree is the exposure. Publishing to a topic is how a device reports state, and subscribing to # is how a client receives all of it. A broker permitting anonymous subscribe hands an unauthenticated client the entire telemetry stream of the deployment. In industrial settings that stream reveals what equipment is running, which doors are open, and how full a tank is.

The publish direction is worse and less discussed. A broker that accepts anonymous publish lets a client write a value that downstream systems act on. Whether that matters depends on what subscribes to the topic, and the answer frequently includes a building management system or a supervisory control layer.

What the numbers do not say

5.6 million matches is a large number and says nothing about which brokers accept anonymous connections. Many sit on private networks reachable from the index only because a router was misconfigured, and some are honeypots.

The defensible reading is a distribution rather than a verdict: there is an enormous installed base of a protocol whose reference configuration is permissive, and some fraction of it is reachable. If your organisation runs MQTT anywhere, the question is whether that fraction includes you.

A query plan for your own network

1. Run both dorks scoped to your address space and netblocks, then reconcile. Anything appearing on a non-1883 port is either a deliberate hardening decision or an exposure nobody recorded.
2. For each match, attempt an anonymous connect. A broker that accepts one is a finding regardless of version.
3. If anonymous connect succeeds, check whether subscribing to # returns data and whether that data carries identifiers of real equipment.
4. Check TLS. A broker accepting plaintext on any port sends telemetry unencrypted, and the lack of encryption is independent of whether authentication is required.
5. Look separately for the administrative interface. Mosquitto, EMQX and HiveMQ all ship management consoles, and a console is a different exposure from a broker.

The closing point that matters

The protocol's permissive defaults are not a flaw. They are a design decision that made a large ecosystem possible, and the cost is paid by operators who deploy a broker and never revisit the configuration file. The index number measures that cost; it is not a criticism of the protocol.

References

• ZoomEye search: https://www.zoomeye.org/
• OASIS MQTT specification and security considerations: https://mqtt.org/