Port 1883 – MQTT (Message Queuing Telemetry Transport)

Port 1883 is the default port for MQTT (Message Queuing Telemetry Transport), the lightweight publish/subscribe protocol that has become the dominant messaging backbone of the Internet of Things. Devices don’t talk to each other directly — they connect to a central broker (commonly Eclipse Mosquitto, EMQX, or HiveMQ), publish messages to hierarchical topics (like home/livingroom/temp or fleet/truck12/gps), and subscribe to the topics they care about. On port 1883 all of that traffic is cleartext — MQTT over TLS lives on port 8883 instead. The problem is that an enormous number of brokers on 1883 accept anonymous connections by default, and once you’re connected you can read and write the entire message bus.

Why It’s Open

MQTT was designed for constrained devices and unreliable networks, so brokers are built to be trivial to stand up — which is exactly why so many end up exposed. Eclipse Mosquitto, by far the most common broker, historically shipped with allow_anonymous true as the default (this only flipped to false in Mosquitto 2.0, released in late 2020), so countless deployments on older versions accept any client that connects, with no username or password at all. Add to that the fact that MQTT is the default transport in home-automation stacks (Home Assistant, Zigbee2MQTT, Tasmota, OwnTracks), industrial/SCADA telemetry, connected-vehicle fleets, and cheap consumer IoT, and you get a protocol that is deployed everywhere, often by people who never touched the security config. Port 1883 stays open because the device fleet needs a rendezvous point — and all too often that rendezvous point is reachable from the public internet.

Common Risks

• Anonymous access by default. A broker that allows anonymous connections lets anyone who can reach 1883 become a full participant on the message bus — no credentials required.
• Total data exposure via the # wildcard. MQTT lets a client subscribe to #, the multi-level wildcard that matches every topic on the broker. One subscription and an attacker receives every message flowing through it — sensor telemetry, GPS coordinates, door/lock states, temperatures, and frequently credentials or tokens published in cleartext.
• Unauthorized publish to control topics. MQTT is bidirectional. If devices act on commands published to topics like home/garage/door/set, an attacker who can publish can open doors, actuate relays, spoof sensor readings, and issue device commands directly.
• No transport encryption. Everything on 1883 is plaintext, so anyone on the network path can passively sniff messages and credentials. Encryption requires moving to port 8883 (MQTTS) — the TLS variant.
• Retained messages and Last Will leak state. Brokers store the last retained message per topic and deliver it to new subscribers instantly, so even a brief connection can dump the current state of the whole system.
• Denial of service. Several broker builds crash or exhaust memory on malformed or oversized packets (see CVEs below), knocking an entire device fleet offline.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

MQTT enumeration is unusually direct: connect, subscribe to the wildcard, and watch the traffic. The Mosquitto client tools ship with almost every distro’s mosquitto-clients package.

Detect the service and version

nmap -sV -p 1883 <target>

Subscribe to the wildcard and sniff every message

mosquitto_sub -h <target> -t '#' -v

The # topic matches everything; -v prints the topic name alongside each payload. If this returns traffic without prompting for credentials, the broker is anonymous and you are reading the entire bus. Also try the broker’s own diagnostics tree: mosquitto_sub -h <target> -t '$SYS/#' -v dumps broker version, uptime, client counts, and bytes transferred.

Publish to a control topic (authorized testing only)

mosquitto_pub -h <target> -t 'test/injection' -m 'pentest'

If a publish to a device’s command topic actually changes device state, you’ve confirmed unauthenticated control — one of the highest-severity findings on this port.

Enumerate with the nmap NSE script

nmap -p 1883 --script mqtt-subscribe <target>

The mqtt-subscribe script connects to the broker, subscribes to topics, and reports the messages it captures.

Deeper assessment with dedicated tooling

For structured broker assessment — credential brute-forcing, topic enumeration over time, and known-topic harvesting — use MQTT-PWN (an IoT-broker pentest framework) or a GUI client like MQTTX for interactive exploration. To find exposed brokers at internet scale, Shodan indexes them under the MQTT Connection Code banner and port:1883.

Capture every open port 1883, every topic tree you can read, and every control topic you can write, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

MQTT’s real-world risk is overwhelmingly design and misconfiguration — anonymous access, the # wildcard, and cleartext transport — rather than memory-corruption RCE. There is no “port 1883 RCE” to chain; the confirmed broker CVEs are mostly denial-of-service and access-control bugs in Eclipse Mosquitto and the protocol itself. Each of the following was verified against its NVD record:

• CVE-2017-7650 — Eclipse Mosquitto 0.15 through 1.4.11. Pattern-based ACLs can be bypassed by clients that set their username or client id to # or +, letting a client reach topics it should not have access to. CVSS 6.5. This is the wildcard problem turned into an authorization bypass.
• CVE-2017-7651 — Eclipse Mosquitto 1.4.14. An unauthenticated attacker can exhaust the broker’s RAM with many connections carrying large payloads, shutting the server down. CVSS 7.5 (DoS).
• CVE-2019-11779 — Eclipse Mosquitto 1.5.0 to 1.6.5. A SUBSCRIBE packet whose topic contains roughly 65,400 or more / separators triggers a stack overflow and crashes the broker. CVSS 6.5 (DoS).
• CVE-2021-34432 — Eclipse Mosquitto 2.0.7 and earlier. The broker crashes when a client sends a PUBLISH packet with a zero-length topic. CVSS 7.5 (DoS).
• CVE-2020-13849 — A design flaw in MQTT 3.1.1 itself: the spec’s Keep-Alive timeout handling lets an attacker exhaust a server’s ability to accept new connections, demonstrated by the SlowITe low-bandwidth DoS tool. CVSS 7.5 (DoS).

No fabricated or wrong-service CVEs were carried into this page. If you’re assessing a specific broker, check that product and version’s advisories directly (Mosquitto, EMQX, and HiveMQ each publish their own) — but treat the anonymous-access and wildcard exposure as the primary finding regardless of CVE status.

Mitigation

• Require authentication. Set allow_anonymous false (the default since Mosquitto 2.0) and enforce a username/password file or, better, client certificates. No broker should accept anonymous clients on an exposed interface.
• Enforce topic ACLs. Restrict each client to only the topics it needs to publish or subscribe to, and never let untrusted clients subscribe to # or $SYS/#. Patch to a Mosquitto build past CVE-2017-7650 so the #/+ ACL bypass can’t be used.
• Use TLS — move to port 8883. Run MQTT over TLS on port 8883 so credentials and payloads aren’t sniffable, and disable plaintext 1883 on anything internet-facing.
• Firewall port 1883 to the device network only. A broker should almost never be reachable from the public internet; audit cloud security groups for an accidental 0.0.0.0:1883.
• Patch the broker. Keep Mosquitto/EMQX/HiveMQ current to close the DoS bugs above, and rate-limit connections to blunt resource-exhaustion attacks.
• Don’t publish secrets to topics. Treat the message bus as readable and keep credentials, tokens, and PII off it.

Real-World Example

In a widely cited 2018 study, security firm Avast scanned the internet for exposed MQTT brokers and found roughly 49,000 open, unauthenticated brokers, including installations tied to smart homes, industrial systems, and even prisons. Because the brokers allowed anonymous access, a subscriber to the # wildcard could read live smart-home telemetry — door and window sensors, energy meters, and home-automation state — and in many cases publish back to control topics, meaning an attacker could unlock doors, toggle alarms, or manipulate devices remotely. Separate research on fleet-tracking and OwnTracks-style GPS deployments found brokers streaming live vehicle and personal location data to anyone who connected. The common thread is never an exotic exploit: it’s an internet-facing broker on 1883 that never turned anonymous access off, letting a single mosquitto_sub -t '#' command lay the whole system bare — the same lesson that makes cleartext IoT services like Telnet on port 23, unauthenticated SNMP on port 161, and open RTSP camera streams on port 554 such reliable footholds.

FAQ

What is port 1883 used for?

Port 1883 is the default port for MQTT, a lightweight publish/subscribe messaging protocol used to connect IoT devices, sensors, and applications through a central broker. Devices publish messages to named topics and subscribe to the topics they care about. Traffic on 1883 is unencrypted; the TLS-secured version of MQTT uses port 8883.

Is port 1883 secure?

Not by default. Many brokers on 1883 accept anonymous connections, and the port carries no transport encryption. Anyone who can reach it can often subscribe to the # wildcard and read every message, and sometimes publish commands back to devices. It becomes reasonably secure only when you require authentication, enforce topic ACLs, and move to TLS on port 8883.

What is the difference between port 1883 and 8883?

Port 1883 is plaintext MQTT — messages and credentials travel unencrypted. Port 8883 is MQTT over TLS (sometimes called MQTTS), which encrypts the entire session and supports certificate-based client authentication. For any deployment crossing an untrusted network, use 8883 and disable 1883.

Can an attacker read all messages on an MQTT broker?

If the broker allows anonymous access or the attacker has any valid credentials without topic restrictions, yes. Subscribing to # (the multi-level wildcard) matches every topic on the broker, so a single subscription streams all traffic. This is why locking down anonymous access and enforcing per-client topic ACLs is the core mitigation.

Does MQTT have serious CVEs?

The confirmed broker CVEs (in Eclipse Mosquitto and the protocol itself) are mainly denial-of-service and access-control bugs — CVE-2017-7651, CVE-2019-11779, CVE-2021-34432, and CVE-2020-13849 among them — not remote code execution. MQTT’s biggest real-world risk is design and misconfiguration: anonymous access, wildcard exposure, and cleartext transport.

How do I secure port 1883?

Set allow_anonymous false, require username/password or client certificates, enforce topic ACLs so clients can’t subscribe to #, move traffic to TLS on port 8883, firewall 1883 to the device network, and keep the broker patched. Then rescan with nmap -p 1883 <target> and confirm an anonymous mosquitto_sub -t '#' no longer returns data.

TL;DR

• Service: MQTT — publish/subscribe messaging broker for IoT (Mosquitto, EMQX, HiveMQ)
• Default port: 1883/TCP plaintext (8883/TCP for MQTT over TLS)
• Biggest risk: anonymous brokers that let anyone subscribe to the # wildcard and read every message — or publish to control topics and actuate devices — with no encryption on the wire
• Mitigation: disable anonymous access, enforce topic ACLs, move to TLS on 8883, firewall 1883 to the device network, and patch the broker. Log every finding in your pentest report