Exposed MQTT Brokers on the Internet: The Risks of Open Port 1883

Exposed MQTT brokers are servers that accept connections from anywhere on the internet, often on plain port 1883 and without authentication. This article explains what an attacker or a curious stranger can see and do on such a broker, how to check whether one of your own brokers is exposed, and how to fix it. You will finish with a short audit checklist and a clear rule for where test data and production data belong.

Why Exposed MQTT Brokers Keep Appearing

MQTT was designed to be simple. A default broker install typically listens on TCP port 1883, and some older or development-oriented configurations allow anonymous connections out of the box. That is perfect on a laptop and dangerous on a cloud VM with a public IP address.

Security researchers and search engines that index internet-connected services have repeatedly reported large numbers of brokers that answer on port 1883 and accept a connection without credentials. The pattern behind them is usually the same:

• A developer starts Mosquitto or another broker on a VM to get a prototype working.
• The cloud firewall or security group is opened for 1883 "temporarily" so field devices can reach it.
• Anonymous access stays enabled because the devices were never given credentials.
• The prototype quietly becomes production.

None of these steps feels risky in isolation. Together they create a message bus that anyone can read and write.

What an Open Broker Exposes

To understand the risk, remember what an MQTT broker does: it routes every published message to every matching subscriber. If anyone can connect, anyone can become a subscriber, and the multi-level wildcard # matches every topic the broker handles.

The write side is often underestimated. If a smart relay subscribes to home/garage/door/set and the broker accepts anonymous publishers, the door is controlled by whoever finds the broker. In industrial settings, the same pattern affects setpoints and machine commands. That is why MQTT security is about authorisation as much as about encryption.

Information Leaks Without Any Attack

You do not need malicious intent for damage to happen. A topic tree like acme/plant2/line4/press7/fault tells a competitor about your plant layout. Retained messages may include firmware versions, which helps anyone looking for devices with known bugs. Debug topics often carry stack traces, IP addresses or full configuration dumps. The safe assumption is that anything published to an open broker is public.

How to Check Whether Your Own Broker Is Exposed

Only test brokers that you own or are explicitly authorised to test. The goal here is to confirm your own configuration from the outside, the same way an internet scanner would see it.

Run these checks from a network that is outside your corporate or cloud network, such as a mobile hotspot:

# 1. Is the plain MQTT port reachable from the internet?
nc -vz your-broker.example.com 1883

# 2. Does it accept an anonymous connection? (your own broker only)
mosquitto_sub -h your-broker.example.com -p 1883 -i audit-anon-check -t 'audit/probe' -W 5 -v

# 3. Does the TLS port present a valid certificate?
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null | head -20

Interpret the results like this:

1. If nc reports the port open and you did not intend to offer plain MQTT publicly, close it at the firewall.
2. If mosquitto_sub connects and waits instead of failing with "not authorised", anonymous access is enabled. Disable it.
3. If the certificate is self-signed, expired or does not match the hostname, clients either fail or, worse, have been configured to skip verification.

Also review your broker configuration directly. In Mosquitto 2.x, for example, a listener without allow_anonymous false and a password or auth plugin is a red flag. Check every listener, including WebSocket listeners on ports such as 8083 and 9001, which are frequently forgotten.

How to Fix an Exposed MQTT Broker

Work through these steps in order. The first three remove most of the risk in an afternoon.

1. Require authentication on every listener. Issue a unique username and password, or a client certificate, per device or per service. Shared credentials make revocation impossible. The guide on MQTT username and password authentication covers the practical setup.
2. Close port 1883 to the internet. Keep plain MQTT for localhost or a private network, and expose only TLS on 8883 (and secure WebSockets if browsers need access).
3. Enable TLS with a certificate from a trusted CA. Clients should verify the server certificate and hostname. See MQTT TLS configuration for client and broker settings.
4. Restrict what each identity may publish and subscribe to. On a self-hosted broker, use ACLs so a temperature sensor cannot subscribe to # or publish commands. The MQTT ACL guide shows common patterns.
5. Remove sensitive data from payloads and retained topics. Clear retained messages you no longer need by publishing an empty retained message to the topic.
6. Apply limits. Cap connections, message size and message rate so a single client cannot exhaust the broker.
7. Patch and monitor. Keep the broker version current and watch for repeated failed logins.

If that list sounds like an ongoing job rather than a one-off fix, that is because it is. It is one of the main reasons teams move to a managed MQTT broker instead of operating an internet-facing server themselves.

Public Test Brokers Versus Private Brokers

There is an important distinction between an accidentally exposed broker and a deliberately public one. A public test broker is designed to be open: anyone can connect, anyone can subscribe, and everyone understands the data is visible. It is a tool for learning and quick experiments.

ConnectMQ runs one at broker.connectmq.com. It accepts anonymous clients with any non-empty, unique client ID, and it applies conservative limits per client, such as 64 KB per message, 10 messages per second and 10 subscriptions. That makes it ideal for trying out code:

mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-7f3a -t 'connectmq/demo/7f3a/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-7f3a -t 'connectmq/demo/7f3a/hello' -m 'test message'

The rule is simple: the public MQTT test broker is for test data only. Never publish real customer data, credentials, locations or control commands for real equipment to any public broker. Use a unique topic prefix such as connectmq/demo/<random-id>/ so your experiments do not collide with others.

When your project moves beyond experiments, it needs a private broker with authentication and TLS. On ConnectMQ, creating one gives you generated credentials, and client IDs are bound to those credentials, so a leaked client ID alone is not enough to connect.

What a Managed Broker Changes

Moving to a hosted service does not make you secure automatically, but it removes the most common causes of exposure. On a ConnectMQ private broker:

• Connections require the username and password generated in the portal.
• TLS is available on port 8883 and secure WebSockets on 8084 with a Let's Encrypt certificate, so clients can verify the server without custom CA files.
• Tenants are isolated from each other in the multi-tenant cluster.
• Per-plan quotas, flood protection and IP blocking after repeated failed logins limit abuse.

You still own your side: protect credentials on devices, use TLS in production, and design topics so they do not leak information. For a full overview of options, the cloud MQTT broker guide compares deployment models, and the MQTT security best practices article covers the client side in depth.

Quick Audit Checklist

Use this list for every broker you operate:

1. No listener accepts anonymous connections unless it is intentionally public.
2. Port 1883 is not reachable from the internet; TLS is enforced on public endpoints.
3. Each device or service has its own credentials, and you know how to revoke them.
4. Clients verify the server certificate and hostname.
5. No secrets, personal data or control topics are published on public test brokers.
6. Retained messages contain nothing you would not want a stranger to read.
7. Connection, size and rate limits are configured.
8. Failed logins are visible and repeated failures are blocked.

Get Started with a Private ConnectMQ Broker

If your prototype is running on an open broker today, the quickest fix is to move it to a private one. Create a broker on the free Serverless plan at app.connectmq.com, with no credit card required, copy the generated credentials, and switch your clients to mqtts:// on port 8883. Your test code keeps working on broker.connectmq.com while production data stays private.

Frequently Asked Questions

Is port 1883 always insecure?

Port 1883 carries unencrypted MQTT, so credentials and payloads travel in clear text. It is acceptable on localhost or an isolated network, but internet-facing endpoints should use TLS on 8883.

How do I know if strangers are reading my broker?

Without authentication you cannot reliably tell, because any client can subscribe to # silently. Treat an anonymous internet-facing broker as already exposed and rotate any secrets it has carried.

Is it safe to use broker.connectmq.com for my project?

It is safe for learning and testing with non-sensitive data. Because it is public by design, anything published there can be read by others, so production systems should use a private broker with credentials.

Does disabling anonymous access stop all attacks?

No, but it removes the easiest one. Combine authentication with TLS, per-client authorisation, limits and patching for real protection.