MQTT exposure check: is your broker reachable without authentication?
How does this check work, and what does the result tell you?
AdminKit checks whether the public IP you are connecting from has an MQTT broker reachable from the internet, attempting a single anonymous CONNECT on port 1883 by default, so it reads back whether the broker accepts the connection without credentials, never subscribing to or publishing on any topic.
Part of the Machine protocols cluster — more tools, guides and terms on machine protocols.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
This checks only the public IP address you are connecting from right now — never a host you type in, and never someone else's broker. It attempts a single anonymous CONNECT, in plaintext, over whatever port you give it; it never subscribes to or publishes on any user-defined topic.
Next step
Also see Modbus exposure, or check other commonly exposed ports on the same IP.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up when this result changes? Talk to our team and we'll set it up for you.
How it works and limits
MQTT is the publish/subscribe protocol, defined by the MQTT Version 5.0 OASIS standard, that most IoT devices and home-automation hubs use to talk to each other and to the cloud; see mqtt.org for a plainer overview of how the protocol works. Many broker deployments ship with anonymous access enabled by default for ease of setup, and are never locked down before going live on the internet.
What it checks
- Whether the public IP you are connecting from answers an anonymous MQTT
CONNECTon port 1883 by default, or a port you specify. - The broker’s own
CONNACKresponse: whether that unauthenticated connection was accepted or refused. - When the connection is accepted, whether the broker’s own
$SYS/broker/versionstatus value is also readable without authentication — a second, lower-severity signal that broker internals are exposed too.
What it won’t do
- It never subscribes to, reads, or publishes on any user-defined topic — no sensor data, device state, or commands are ever read.
- It never sends a username or password; it only observes whether the broker demanded one.
- It never probes a host you did not request the check against — see “Why does it only check my own IP?” below.
Limits
- “Anonymous access allowed” means the broker accepted a credential-free session — itself a meaningful exposure, since anyone who can reach the broker could do the same and then read or publish on every topic it carries — it is not a statement about separate, implementation-specific vulnerabilities a given broker might also carry.
- Today’s check always attempts the connection in plaintext regardless of the port you give it; see the FAQ above for what that means if your broker only accepts MQTT over TLS on 8883.
- No query is logged; see /legal/privacy/.
Check manually today
With the mosquitto client tools installed, the same anonymous-connection question this tool answers looks like:
mosquitto_sub -h <host> -p 1883 -t '#' -v -C 1
If this connects and prints a message (or simply connects without an authentication error) within a few seconds, the broker accepts anonymous connections — only run this against a broker you own or are authorized to test.
If this turns up an open broker, see how to secure an MQTT broker for the fix. See also is port 8883 (MQTTS) exposed? for the TLS variant, the glossary entry for MQTT, and AdminKit’s RTSP camera exposure check for a related machine-protocol self-check that works the same way. AdminKit does not build an internet-wide index of devices the way Shodan or Censys do — this check only ever looks at the IP you are connecting from.
Frequently asked questions
Is this check live?
Yes — it sends a real anonymous CONNECT via AdminKit's Check API (POST /v1/check/mqtt), the same endpoint anyone can call anonymously, rate-limited per visitor. Like AdminKit's open ports and RTSP exposure checks, it only ever probes the public IP address the request comes from or an asset you've verified ownership of — there is no field to type in someone else's broker, so this works as a live, self-check tool for every visitor today.
Will it read or publish any topic?
No. It sends one anonymous CONNECT and, only if the broker accepts it, reads a single broker-status value most broker implementations expose by convention at $SYS/broker/version (this is not part of the MQTT specification itself, just a widely followed broker convention) — internal metadata about the broker software, never a topic you or your devices publish. It never subscribes to or publishes on any user-defined topic, and it always sends a clean DISCONNECT afterwards.
What does 'anonymous access allowed' mean?
It is read directly from the broker's own CONNACK response code to an unauthenticated CONNECT: a success code means anonymous access is allowed, a 'not authorized' or similarly-coded rejection means it is not — AdminKit does not guess a password or try more than one credential-free attempt.
Why does it only check my own IP, not a broker I don't own?
Like every active AdminKit check, an MQTT probe only runs against your own IP or an asset you've verified ownership of — an unverified host gets no active connection attempt at all. That is also why the check always reads your current public IP automatically rather than offering a field to type a host into: no other address could be checked with your permission.
What if my broker's MQTT port isn't 1883?
Enter the external port your router actually forwards before running the check. One limitation to know: the self-check always attempts the connection in plaintext, even if you enter 8883 (the standard MQTT-over-TLS port) — a broker that requires a TLS handshake immediately, before any MQTT data, will correctly come back as unreachable rather than falsely confirming anonymous access over an encrypted channel it never actually negotiated.