CVE-2016-9877

What it actually does

MQTT authentication bypass allowing successful connection when a valid username is supplied but the password field is omitted from the request.

Why it matters to the business

Attackers can gain unauthorized access to the message broker, enabling interception or injection of messages that disrupts operations and compromises data confidentiality across dependent systems.

How an attack unfolds

An attacker sends a crafted MQTT CONNECT packet containing only a valid username with no password field; the server incorrectly grants the session, after which the attacker can subscribe to or publish on any accessible queues or topics.

How to fix it

Upgrade RabbitMQ to version 3.5.8 or later for the 3.5.x branch and 3.6.6 or later for the 3.6.x branch; for RabbitMQ for PCF use 1.5.20+, 1.6.12+, or 1.7.7+; enforce TLS with client certificates for MQTT listeners.

How to confirm the fix worked

Confirm server version meets or exceeds the fixed releases; test by attempting an MQTT connection supplying only a username and verify the attempt is rejected; review listener configuration to ensure passwordless MQTT is disabled.

Typical attack path

1. Scan for exposed RabbitMQ MQTT ports
2. Collect or guess valid usernames from public directories or prior breaches
3. Send MQTT CONNECT request with username only
4. Receive successful CONNACK and establish session
5. Subscribe to or publish messages on sensitive queues

How to detect it

Inspect RabbitMQ connection logs and MQTT protocol traces for CONNECT packets that contain a username but lack a corresponding password field or have an empty password.

What your security team should do

• Apply the listed version upgrades immediately
• Disable MQTT plugin if not required or restrict it to authenticated TLS client-certificate connections only
• Monitor connection logs for anomalous MQTT sessions lacking password data
• Review all downstream applications that depend on the broker for exposure