[Paper Review] Security assessment of common open source MQTT brokers and clients

Edoardo Di Paolo, Enrico Bassetti+1 more|arXiv (Cornell University)|Sep 7, 2023

IoT and Edge/Fog ComputingComputer Science3 citations

TL;DR

This paper presents an empirical security evaluation of five open-source MQTT brokers and three client libraries using dynamic fuzzing to identify deviations from the MQTT standard that could lead to security issues. While no critical vulnerabilities were found, several brokers exhibited non-compliant behavior—such as improper handling of QoS 2 messages, topic length limits, and out-of-order packet processing—creating potential attack vectors for denial-of-service or replay attacks, with Mosquitto showing the strongest standard adherence.

ABSTRACT

Security and dependability of devices are paramount for the IoT ecosystem. Message Queuing Telemetry Transport protocol (MQTT) is the de facto standard and the most common alternative for those limited devices that cannot leverage HTTP. However, the MQTT protocol was designed with no security concern since initially designed for private networks of the oil and gas industry. Since MQTT is widely used for real applications, it is under the lens of the security community, also considering the widespread attacks targeting IoT devices. Following this direction research, in this paper we present an empirical security evaluation of several widespread implementations of MQTT system components, namely five broker libraries and three client libraries. While the results of our research do not capture very critical flaws, there are several scenarios where some libraries do not fully adhere to the standard and leave some margins that could be maliciously exploited and potentially cause system inconsistencies.

Motivation & Objective

• To assess the security and protocol compliance of widely used open-source MQTT broker and client libraries.
• To identify implementation deviations from the MQTT standard that could lead to exploitable security issues.
• To evaluate the behavior of real-world IoT devices, such as the Shelly DUO Bulb, under non-standard MQTT message patterns.
• To investigate whether non-compliant behaviors in brokers or clients could lead to system inconsistencies or vulnerabilities.

Proposed method

• Conducted dynamic security testing using fuzzing techniques to inject malformed or non-standard MQTT messages into broker and client libraries.
• Designed test cases targeting ambiguous or underspecified parts of the MQTT protocol standard, especially around QoS levels, packet ordering, and topic length.
• Evaluated five broker libraries (Aedes, EMQX, HiveMQ, Mosquitto, VerneMQ) and three client libraries (Eclipse Paho, Mosquitto, and a client from a Shelly DUO Bulb) under controlled conditions.
• Monitored responses for protocol violations, such as incorrect state transitions, unexpected disconnections, or crashes.
• Applied real-world device testing by interacting with an MQTT client embedded in a Shelly DUO Bulb to assess practical implications.
• Analyzed the impact of delayed, reordered, or modified packets to simulate man-in-the-middle or network injection attacks.

Figure 1: Typical MQTT architecture: IoT devices (clients) publish their messages to the broker. Subscribers ask the broker to receive only those messages with topics they subscribe. Broker relays (publishes) to each subscriber only messages with subscribed topics.

Experimental results

Research questions

• RQ1 How do popular open-source MQTT broker implementations deviate from the MQTT standard under non-standard message inputs?
• RQ2 What security risks arise from non-compliant handling of QoS 2 message sequences in MQTT brokers?
• RQ3 Can topic length violations lead to denial-of-service conditions in MQTT clients or brokers?
• RQ4 How do client libraries respond to malformed or non-standard MQTT messages, and do they exhibit robustness issues?
• RQ5 To what extent do real-world IoT devices exhibit insecure behaviors when exposed to non-compliant MQTT traffic?

Key findings

• Aedes and other brokers exhibited out-of-order handling of PUBCOMP packets, creating a potential vector for replay attacks that could disrupt or damage mechanical IoT devices.
• Publishing to topics longer than 4096 bytes caused disconnections in most brokers, with Aedes experiencing a complete broker crash, leading to a network-wide denial-of-service.
• All brokers except Mosquitto violated the QoS 2 'unique identifier' requirement in different ways during double-publish tests, creating interoperability risks.
• Mosquitto was the only broker to fully comply with the MQTT standard across all test cases, demonstrating the strongest security posture among evaluated implementations.
• Client libraries showed minor issues, primarily related to encoding errors or long topic subscriptions, but were generally more robust than several brokers.
• The Shelly DUO Bulb's MQTT client behaved consistently under test, indicating that embedded clients can be secure when properly implemented.

Figure 2: Schema of the testbed for the experiments: the fuzzer, which acts as a typical client, takes in input a “JSON experiment file” containing the client’s packets to the MQTT broker. The fuzzer will also receive all the PUBLISH packets sent to the broker. The MQTT Client, instead, uses one of