# MQTT Unauthenticated Access

- **URL:** https://hackindex.io/services/mqtt/vulnerability-discovery/mqtt-unauthenticated-access
- **Path:** MQTT > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/mqtt/vulnerability-discovery.md)
- **Published:** 2026-03-16
- **Updated:** 2026-03-16

MQTT brokers that accept connections without credentials allow any client on the network to subscribe to all topics and publish to any topic they have not been explicitly ACL'd off. The MQTT specification makes authentication optional, and many broker deployments (particularly in IoT and industrial environments) leave it disabled. This is the most common MQTT security finding.

## MQTT Broker Fingerprinting: Confirm Anonymous Connection

Attempt a connection with no username or password. The CONNACK return code tells you immediately:

```bash
mosquitto_sub -h $TARGET_IP -p 1883 -t '#' --retained-only -C 1 -v 2>&1
# Client mosqsub|1234-kali sending CONNECT
# Client mosqsub|1234-kali received CONNACK (0)
```

CONNACK code 0 without supplying `-u` or `-P` flags confirms anonymous access is accepted. Any payload output alongside the CONNACK confirms subscribe access too.

Explicitly connect with empty credentials to distinguish "no auth required" from "empty string accepted":

```bash
mosquitto_sub -h $TARGET_IP -p 1883 -t '#' -u '' -P '' --retained-only -C 1 -v 2>&1
```

If both return CONNACK 0, the broker accepts unauthenticated connections regardless of whether credentials are supplied.

## Confirm Anonymous Subscribe Works

A connection being accepted does not guarantee subscribe permission: ACLs can allow connection but restrict topic access. Verify subscribe actually returns data:

```bash
mosquitto_sub -h $TARGET_IP -p 1883 -t '#' -v -C 10 2>&1
```

Receiving any message output confirms subscribe access is open. If the connection is accepted but no messages are received even after waiting, the broker may have ACLs that deny wildcard subscriptions: try specific topic paths.

## Confirm Anonymous Publish Works

Publish a test message to a benign topic to confirm write access:

```bash
mosquitto_pub -h $TARGET_IP -p 1883 -t 'pentest/probe' -m 'test' -d 2>&1
# Client mosqpub|1234-kali sending CONNECT
# Client mosqpub|1234-kali received CONNACK (0)
# Client mosqpub|1234-kali sending PUBLISH (d0, q0, r0, m1, 'pentest/probe', ... (4 bytes))
# Client mosqpub|1234-kali sending DISCONNECT
```

A successful PUBLISH without authentication confirms full unauthenticated read/write access. This feeds directly into [Unauthorized MQTT Publish](https://hackindex.io/services/mqtt/exploitation/mqtt-unauthorized-publish).

Use a harmless topic path like `pentest/probe`: avoid publishing to device control topics during the verification step.

## Check TLS Port Separately

If both 1883 and 8883 are open, test each independently. A broker may enforce authentication on the plaintext port but not on TLS, or vice versa:

```bash
mosquitto_sub -h $TARGET_IP -p 8883 --insecure -t '#' --retained-only -C 1 -v 2>&1
```

Document which ports accept anonymous connections.

## Document the Finding

Record:

- Port(s) accepting anonymous connections
- Whether anonymous clients can subscribe (read)
- Whether anonymous clients can publish (write)
- Whether `$SYS` topics are readable without authentication
- MQTT protocol version in use

## References

- [Mosquitto: Authentication Methods](https://mosquitto.org/documentation/authentication-methods/) - Configuration reference for enabling authentication on Mosquitto brokers
- [MQTT 3.1.1 Specification: CONNECT](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718116) - CONNACK return code definitions and authentication field behaviour