Internet-exposed pub/sub services create hidden data exposure risk

At a glance

What this is: This analysis shows that internal pub/sub systems, especially MQTT, ZeroMQ and NATS, are frequently exposed on the public internet and can leak live operational data to unauthenticated clients.

Why it matters: It matters because identity and access controls often stop at well-known application edges, while internal messaging layers can bypass those assumptions and expose telemetry, credentials or control signals.

By the numbers:

• more than 28k MQTT servers
• 9,491 ZeroMQ publisher sockets
• 3,979 unauthenticated NATS hosts

Context

Pub/sub messaging is a control plane for internal system communication, not usually a user-facing service, which is why exposure often goes unnoticed until someone tests the protocol directly. When MQTT, ZeroMQ or NATS is reachable from the internet, the issue is usually not the protocol itself but the assumption that the service would never be externally addressable.

This article focuses on a governance gap that sits between network exposure and access control. Network ports and protocols can be easy to overlook when teams classify only standard web services as internet-facing, and that blind spot is exactly what makes pub/sub exposure persistent.

Key questions

Q: How should security teams govern unauthenticated pub/sub services on the internet?

A: Treat public messaging endpoints as governed assets, not hidden implementation details. Require authentication, topic-level authorisation, and explicit ownership for every exposed broker or socket. Then test from outside the trust boundary to confirm that subscriptions fail for unauthenticated clients and that published data is not visible unless a policy explicitly allows it.

Q: Why do exposed MQTT, ZeroMQ and NATS services create security risk?

A: They collapse the boundary between internal system traffic and public reachability. If a service accepts unauthenticated connections, external observers can read operational data, and in some cases inject messages that influence downstream consumers. The risk is highest when telemetry, control signals or secrets are mixed into streams that were assumed to be private.

Q: What are the signs that internal messaging is exposed too broadly?

A: Look for public IPs, cloud security groups, open broker ports, default or absent authentication, and topics that accept subscriptions from unknown clients. If a short external connection test returns live events, the service is already operating outside its intended trust boundary and needs immediate ownership and access review.

Q: What should teams do when an internal pub/sub channel is reachable from outside?

A: First contain the exposure by restricting network access and disabling unauthenticated access paths. Then identify what data the stream carries, which systems depend on it, and whether any secrets, credentials or control messages have already been exposed. After that, rebuild the trust model around authenticated consumers and explicit topic access.

Technical breakdown

Why unauthenticated pub/sub exposure matters

Publish-subscribe systems separate publishers from subscribers, so a service can look harmless while still streaming data to anyone who can connect. MQTT often exposes topic subscriptions, ZeroMQ can broadcast events from publisher sockets, and NATS may emit internal events without strong authentication if it is misconfigured. The security problem is not just passive listening. In some deployments, unauthenticated clients can also inject messages or influence downstream consumers. That turns an internal coordination channel into an externally reachable data and control path.

Practical implication: Treat every externally reachable messaging endpoint as a protected control surface, not a convenience layer.

How protocol defaults turn internal messaging into an exposure path

These systems are commonly deployed for reliability, low latency or device coordination, which makes them attractive for internal use and easy to forget in perimeter reviews. ZeroMQ is especially subtle because it is a library, not a broker, so exposed sockets often reflect embedded application logic rather than an obvious standalone service. MQTT and NATS can also be configured with weak or absent authentication, and the practical result is that a broker or socket may faithfully serve data to any unauthenticated client that knows the protocol.

Practical implication: Inventory messaging endpoints separately from applications so exposed sockets do not evade review.

Why the data exposed through pub/sub is often more sensitive than teams expect

Messaging streams frequently carry telemetry, logs, operational events and control signals, which means their sensitivity depends on what consuming systems put into the stream. The article shows that exposed topics can contain usernames, passwords, geolocation, financial transactions and device data. That makes the security question one of data handling as much as network reachability. If message topics are discoverable without authentication, secrecy assumptions fail even when the surrounding application appears to be private.

Practical implication: Classify message content before deployment and restrict topic visibility to authenticated, authorised consumers.

NHI Mgmt Group analysis

Invisible messaging is now an identity and access problem, not just a network hygiene problem. When a pub/sub endpoint accepts unauthenticated connections, the control failure is governance, not transport. The organisation has effectively left an internal system accessible without a trust decision, and that is an access-control failure even if no human login is involved. Practitioners should treat message brokers and embedded sockets as governed identities in the service stack.

Pub/sub exposure creates a hidden trust boundary that many security programmes do not model. Traditional asset inventories tend to prioritise hosts, domains and applications, while messaging endpoints hide inside service code or appliance firmware. That means the risk is often not that the control is missing, but that it was never assigned ownership, reviewed in architecture, or tested from the outside. Teams should explicitly map internal messaging systems into network ports and protocols governance.

MQTT, ZeroMQ and NATS illustrate protocol invisibility as a security failure mode. The article’s central lesson is that obscure or internal-facing technology can become the attacker’s easiest path when exposure is accidental and authentication is optional. This is especially relevant where operational data, device commands or credentials flow through the stream. Practitioners should assume that any unauthenticated messaging path can become a live exposure path, even when the protocol is rarely discussed.

Service messaging endpoints need the same lifecycle discipline as other non-human identities. A broker, socket or topic that can be reached from outside the intended trust zone is effectively a service identity with access scope. If it is not inventoried, authenticated and constrained, it can leak data without any traditional account takeover. Governance teams should extend identity boundaries to the systems that publish and consume messages.

What this signals

Protocol invisibility creates governance debt. The hardest exposures are often the ones that never appear on a normal application inventory because they live inside embedded messaging libraries, broker defaults or appliance firmware. That pushes security teams toward explicit service discovery and away from assumptions about what is or is not internet-facing.

Message streams should be treated as data-bearing identities. Once a topic or socket can emit sensitive events, the security question becomes who can subscribe, what can be published and which data classes are allowed to flow. That is a governance problem as much as a network exposure problem, and it needs ownership in both IAM and operational security programmes.

For practitioners

• Inventory all externally reachable messaging endpoints Scan for MQTT, ZeroMQ and NATS services across public ranges, cloud assets and on-prem networks, then record protocol, socket type, authentication state and ownership in the asset register.
• Require authentication for every pub/sub consumer Block unauthenticated subscriptions and publisher access by default, then allow only explicitly approved identities, topics and transport paths for production messaging.
• Review message content for sensitive operational data Classify topics and streams that carry telemetry, credentials, location data, logs or device commands, and remove secrets or personal data from streams that do not need them.
• Test from the attacker’s perspective before release Validate whether an unauthenticated client can connect, subscribe or receive live events during a short observation window, because that is the condition an external observer will exploit.

Key takeaways

• Publicly exposed pub/sub services can leak live operational data even when they are not traditional web applications.
• The evidence in this article shows that unauthenticated MQTT, ZeroMQ and NATS services are common enough to be a repeatable attack surface, not a corner case.
• The most effective control is to inventory, authenticate and restrict message brokers and embedded sockets before they are reachable from untrusted networks.

Related NHI Mgmt Group resources: Network Ports and Protocols Security Guide

Key terms

• Publish-Subscribe Messaging: A messaging pattern where systems publish events to a topic and subscribers receive them asynchronously. It is efficient for internal coordination, but exposure becomes risky when subscription or publishing is reachable without authentication, because sensitive operational data can be observed or influenced outside the intended trust boundary.
• Unauthenticated Messaging Endpoint: A broker, socket or service that accepts connections or subscriptions without proving identity first. In practice, this means an external client may be able to read, and sometimes influence, internal event streams that were assumed to be private or operationally confined.
• Topic-Based Access Control: A control approach that limits who can publish to or subscribe from specific messaging topics. It matters because pub/sub systems often mix telemetry, logs and control signals, so access needs to be constrained at the topic level rather than by network reachability alone.
• Embedded Messaging Library: A messaging component integrated directly into an application rather than deployed as a standalone server. Because it can create sockets inside software logic, it is easy to miss during inventory and may expose internal communication patterns to the network when misconfigured.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.