Topic starter
25/10/2026 11:07 am
TL;DR: Public MQTT, ZeroMQ and NATS services can leak live operational data because unauthenticated clients can reach them, as Censys found. Public messaging endpoints need ownership and access review before they sit outside the trust boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Censys: “Unauthenticated Message Queues are a Problem”.
By the numbers:
- more than 28k MQTT servers
- 9,491 ZeroMQ publisher sockets
- 3,979 unauthenticated NATS hosts
Key questions
Q: Why do exposed MQTT, ZeroMQ and NATS services create security risk?
A: They collapse the boundary between internal system traffic and public reachability.
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.
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.
Practitioner guidance
- 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.
Bottom line: Publicly exposed pub/sub services can leak live operational data even when they are not traditional web applications.
Glossary terms: Publish-Subscribe Messaging, Unauthenticated Messaging Endpoint, Topic-Based Access Control, Embedded Messaging Library
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Internet-exposed pub/sub services create hidden data exposure risk
This post was modified 7 days ago by NHI Mgmt Group