Introduction
This is a relatively narrow topic that has received little attention, in part because the protocols involved are largely invisible to most users (and even to many engineers who interact with their effects rather than their mechanics). In this post, we examine how internal messaging systems such as MQTT, ZeroMQ, and NATS are sometimes exposed to the public internet, often unintentionally.
It is often the protocols that receive little attention that have the potential to create the most significant problems. An exposed MQTT or NATS service is unlikely to generate the same media attention as a vulnerability like Log4j, not because the impact is smaller, but more because the topic itself is less accessible and does not lend itself to a compelling headline.
In many cases, the organizations behind these exposures may have no idea that the service is publicly accessible at all, let alone accessible to unauthenticated clients. In one case, we observed a drone monitoring system used in prisons that exposed real-time telemetry over ZeroMQ. This is unlikely to be the fault of the facilities themselves, which may not be aware that a vendor relies on this obscure protocol. These cases are often the hardest to identify and debug once unauthorized access has been discovered.
At Censys, we examine exposed services across the entire protocol landscape, including obscure or easily overlooked ones. The reality is that it is often impossible to predict which technologies will become relevant to an attacker. What appears insignificant today may become tomorrow’s problem.
Message Queues and the Pub/Sub Model
One of the more interesting technology concepts that nearly every engineer knows about and has used, but that general society is largely unaware of, is the message queue, and more specifically, the publish–subscribe (pub/sub) model that many networked queue systems implement.
At a high level, these systems solve a fundamentally different problem than request–response protocols like HTTP. Instead of asking for data and waiting for an answer, systems publish messages to a topic or queue, and other systems subscribe to receive them, often as a continuous, asynchronous stream.
At its core, Pub/Sub is a messaging pattern often integrated with various products and services. Over the years, this model has been implemented across a wide range of technologies: lightweight protocols for embedded devices and constrained networks (MQTT), low-latency messaging systems designed for internal service coordination (ZeroMQ and NATS), and many variations in between.
In this post, we focus on a subset of these systems where unauthenticated clients can receive live event data directly from the public internet. Specifically, we examine MQTT, ZeroMQ, and NATS, protocols that are widely deployed, frequently misconfigured, and, in many cases, actively streaming internal operational data to anyone who knows how to connect.
Measuring Internet-Exposed Pub/Sub
While we were able to successfully retrieve messages from more than 28k MQTT servers, as well as thousands of ZeroMQ and NATS services on the internet, the more difficult problem is determining how to objectively assess the severity of that exposure. At the end of the day, we are just a port scanner, and our vantage point is limited to what a service willingly provides to an unauthenticated client.
We intentionally avoid assumptions about intent or sensitivity. The data we observe may represent anything from benign telemetry to critical control signals. In many cases, there is no reliable way to distinguish between the two without additional context that we simply do not have, and that an attacker would not have either.
Our methodology focuses more on observable behaviour, not interpretation; that is, whether a service accepts unauthenticated connections, whether it allows subscriptions, and whether it actively publishes messages during a short observation window.
However, in some cases, the nature of the observed data raised serious ethical concerns. By subscribing to a topic, we encountered material that included real-time financial transactions, application logs containing usernames and passwords in plaintext, and mobile LTE signalling events containing geolocation data and IMEIs associated with logistics operations. While we cannot independently verify the full context or accuracy of that data, its sensitivity was sufficient enough to prompt us to change our approach.
As a result, we halted our original analysis and reworked how we collected and interpreted data from these services. The act of retaining such material posed unnecessary risk, and doing so was not required to demonstrate the problems with these exposures.
MQTT
We begin with MQTT because it is both the most prevalent and one of the most easily abused pub/sub protocols discussed in this article. Its combination of widespread deployment and frequent lack of authentication makes MQTT a natural starting point for understanding the broader landscape of these types of exposures.
Designed for resource-constrained devices operating on unreliable networks, MQTT is widely used to aggregate sensor data and control signals from large fleets of devices. As a result, it is often deployed closer to physical systems than to traditional application-layer services.
It should be noted that the ability to read from or subscribe to a topic on an MQTT service does not necessarily imply the ability to publish messages to it. Different implementations support different access control mechanisms, and write permissions can be more restricted than read access. The same applies to reading from topics: just because the server claims the subscription succeeded, doesn’t mean you will receive anything.
When an unauthenticated client can subscribe to any MQTT topic, sensitive operational data (such as telemetry) may be exposed. If unauthenticated publishing is also permitted, the risk increases further as external clients may be able to inject messages into live systems. And depending on how downstream consumers handle these messages, the effects can range from benign noise to unintended device behavior that could disrupt critical services.
In total, over 650,000 hosts expose one or more MQTT services. Of these, more than 480,000 (approx. 74%) accept unauthenticated connections from any client, and 407,000 allow unauthenticated clients to subscribe to topics.
The chart above breaks MQTT exposure into three categories: the total number of MQTT servers, the number of servers that accepted unauthenticated connections, and the number that allowed unauthenticated subscriptions.
South Korea stands out as the country with the highest overall exposure, with 435,986 MQTT hosts identified. Of these, 430,678 (98.8%) accepted our connection, and 429,084 (98.4%) allowed us to subscribe to one or more topics, meaning that nearly all exposed MQTT services in the country are fully accessible to unauthenticated clients.
China presents a slightly different profile. Out of 155,345 exposed MQTT hosts, 96,274 (61.9%) accepted our connection, and 37,674 (24.2%) allowed unauthenticated subscriptions. While still substantial in absolute terms, this represents a significantly lower proportion of publicly accessible services compared to South Korea.
On a more positive note, the United States shows a significantly lower level of exposure. Of the 36,035 MQTT hosts, only 9,649 (26.8%) accepted unauthenticated connections, and just 7,756 (21.5%) allowed unauthenticated clients to subscribe to topics..
To better understand the real-world impact of this exposure, we conducted a secondary scan to identify MQTT services that were actively publishing data. For each open service, we attempted to subscribe to a global topic and waited up to one minute for at least one message to be delivered. As a result, we observed 28,595 hosts emitting messages during the observation window. This represents approximately 4.4% of all exposed MQTT hosts, or about 7.0% of those that allowed unauthenticated subscriptions.
The data we saw from this sample ranged widely in content. In many cases, messages appeared to contain benign information such as weather telemetry, wireless device statistics, or application-level metrics. In other cases, we observed artifacts such as RTSP URLs for security camera streams and syslog events that seemingly included authentication data.
ZeroMQ
“ZeroMQ supports common messaging patterns (pub/sub, request/reply, client/server and others) over a variety of transports (TCP, in-process, inter-process, multicast, WebSocket, and more), making inter-process messaging as simple as inter-thread messaging. This keeps your code clear, modular and extremely easy to scale.” – ZMQ Documentation.
ZeroMQ (ZMQ) is an interesting case because when you encounter a ZMQ service on the internet, you’re not looking at a centralized broker or a standalone server in the traditional sense. There is no generic zmq-server daemon that listens on a default port. Instead, ZeroMQ is a messaging library, and any exposed service exists only because a piece of software explicitly uses that library and creates and listens on the ZMQ socket. For this analysis, we focus on ZeroMQ services using the publish–subscribe pattern.
As a result, the data you receive from a ZMQ endpoint can be in virtually any format, whatever the application embedding ZeroMQ decided to send. There are no protocol-level schemas or guarantees about structure; this makes ZeroMQ behave less like a conventional network service and more like an advanced RPC or inter-process communication mechanism that has been intentionally (or unintentionally) pushed onto the network layer.
It is almost guaranteed that an exposed ZMQ service is a mistake and was never meant to be accessible to the internet, but there are exceptions; for example, many cryptocurrencies seem to use ZMQ as a transport protocol (which Censys will also discern from the services). It was much more common in the mid-2000s than it is now to see or hear of this protocol, but the services are still very prevalent on the internet, with about 20,000 hosts running one or more ZeroMQ services.
The implication is that when you discover a ZeroMQ service exposed to the internet, you are almost certainly observing the internal messaging layer of an application. What was intended to be private communication between components is now directly accessible to anyone who knows how to connect. Mind you, that doesn’t mean the data will always be in some binary, unreadable format, nor will it always be private information; it can be anything. For example, the screenshot below shows what appears to be a traffic logistics event in JSON format.
Fortunately, the publisher and subscriber roles in ZeroMQ are logically separate. Simply observing that a ZMQ service exposes a publisher (PUB) socket does not imply that the service is writable, and the converse is also true. A subscriber (SUB) socket is not something you can read from; it exists solely to send data into the application embedding ZeroMQ.
Censys distinguishes between these two socket types explicitly:
- host.services.zeromq.handshake.socket_type=PUB ZeroMQ publisher sockets, where the server publishes events to connected subscribers
- host.services.zeromq.handshake.socket_type=SUB ZeroMQ subscriber sockets. A SUB socket is receive-only and is designed to connect to PUB sockets, not to accept published messages from arbitrary peers.
There are 20,102 hosts on the internet running at least one ZeroMQ service. Of these, 9,491 operate publisher sockets without authentication. Because ZeroMQ publisher sockets broadcast messages to all connected subscribers, clients can observe all events sent through the queue, which introduces a risk of unintended data exposure.
| Country | Total ZMQ Hosts | ZMQ Hosts w/PUB Sockets |
| United States | 5,171 | 2,495 |
| China | 4,564 | 1,827 |
| Germany | 1,357 | 922 |
| South Korea | 1,228 | 529 |
| France | 888 | 435 |
| Russia | 497 | 225 |
| Japan | 486 | 216 |
| United Kingdom | 420 | 261 |
| Netherlands | 415 | 252 |
| India | 337 | 209 |
Here we can see that the majority of ZeroMQ hosts are located in the United States, with 5,171 total hosts, 2,495 of which expose a publisher (PUB) socket. China follows closely behind, with 4,564 total ZeroMQ hosts, 1,827 of which operate publisher sockets.
To better understand how many of these exposed publisher services were in active use, Censys conducted a secondary scan to identify which ZeroMQ servers were actually publishing data. This was done by connecting to the service, completing the ZeroMQ handshake, subscribing to an empty topic (which results in receiving messages for all topics), and then waiting for a short period to see if any events were received.
If at least one event was observed, a boolean flag was recorded for that host indicating active publishing. If no events were seen during the observation window, the host was not flagged. No message contents were logged or retained; only the presence or absence of received data was recorded.
Using this approach, we found that of the roughly 9,000 exposed publisher sockets (all unauthenticated by default), 3,616 hosts (38.1%) were actively publishing events at the time of our auxiliary scan.
We can also break this data down by autonomous system to better understand the types of networks where ZeroMQ is deployed, which may provide insight into the kinds of software these services support. However, as we’ll see, looking at global trends across ASNs alone can be misleading.
In the graph above, we see that nearly every autonomous system falls into one of two categories: large cloud providers (such as Amazon, OVH, Google Cloud, and Alibaba) or datacenter-based hosting and VPS providers (including DigitalOcean and Hetzner), with a smaller presence of telecommunications networks (for example, CHINANET/Unicom and Comcast).
As with most internet statistics these days, Amazon hosts the majority of ZeroMQ, with a total of 906 hosts, of which 498 have one or more ZMQ PUB services.
However, when we break this same data down by country, a very different picture emerges. For example, the graph below shows the same distribution, but limited to hosts located in the United States:
The vast majority of internet-exposed ZeroMQ services in the United States are located within AS792 (Comcast). Unlike cloud providers or datacenters, AS7922 primarily provides internet access to residential and small-to-medium business customers rather than hosting infrastructure. In other words, these services are not running in data centers or VPS environments, but rather on networks belonging to local businesses or on-prem deployments.
This suggests that many of the exposed ZeroMQ services observed in the United States are tied to internal operational systems, likely software used for monitoring, coordination, or automation rather than intentionally deployed, internet-facing services. When a service is hosted in a data center or public cloud environment, there is an implicit understanding that it may be externally reachable.
By contrast, exposing a service on a residential or small-business network meant for simply accessing the internet is more akin to placing internal systems in a publicly accessible space, like running backend infrastructure from the lobby of a shop or a public library, where access is neither expected nor properly controlled. This is not always the case, as a business can purchase transit from Comcast for the specific purpose of hosting services, but these services are usually for that business only.
NATS
Neural Autonomic Transport System (NATS) is a lightweight, line-oriented messaging system designed for low-latency communication and simple publish–subscribe semantics between distributed services. While the protocol supports authentication, this is not always enabled in practice.
At the time of analysis, we identified 48,809 hosts running a NATS server, of which 3,979 did not require authentication. And of those, 1,230 hosts were actively emitting events over the Pub/Sub interface.
Although the overall internet footprint of unauthenticated NATS is smaller than that of the other services discussed here, its deployment context makes these exposures particularly concerning. NATS is most commonly found in modern, cloud-based environments and is often used for internal service coordination. As a result, the data flowing through these systems may be more valuable. In a small sample of observed traffic, we identified what looked to be usernames, passwords, authentication tokens, and potentially personally identifiable information being streamed to unauthenticated topics.
| Country | Total NATS Hosts | Unauthenticated NATS Hosts |
| France | 8,697 | 305 |
| United States | 8,192 | 743 |
| Germany | 7,482 | 639 |
| Italy | 7,318 | 18 |
| United Kingdom | 6,679 | 73 |
| China | 1,376 | 718 |
| Switzerland | 1,216 | 23 |
| Canada | 1,017 | 41 |
| Ireland | 1,017 | 29 |
As with ZeroMQ, examining NATS exposure solely through the estimated geolocation can be misleading. The vast majority of exposed NATS servers are concentrated within Amazon’s infrastructure: 37,572 of the 48,809 identified hosts reside in the autonomous systems AMAZON-02 and AMAZON-AES. This may mean that many of these instances are being used as connective layers within cloud-based microservice architectures rather than any type of user-facing service.
However, despite hosting the majority of internet-facing NATS servers overall, Amazon ranks only fourth when it comes to unauthenticated NATS deployments. Just around 6% of all unauthenticated NATS hosts are located within Amazon’s autonomous systems.
Call to Action
Mistakes happen, and the APIs and technologies we rely on can sometimes have unintended consequences when they are not closely monitored or are exposed directly to the internet. The ZeroMQ exposures described above are a good example of this risk. While these systems are often thought of as internal tools or RPC mechanisms, in practice, they can create direct pathways into our data and potential operational systems. When those communication methods are known (as when we know how to speak the underlying protocol), they may be accessed or used in ways never intended.
Censys ASM customers can find these types of unauthenticated services flagged as potential risks in their workspace, and if you’re not an ASM customer, inquire with our sales team: sales@censys.com
