arXiv:2605.15804v1 [cs.CR] 15 May 2026
Security Analysis of a Communication Protocol: MQTT Clarisse Sousa Polytechnic of Porto - School of Engineering
Ricardo Venâncio Polytechnic of Porto - School of Engineering
Informatics Engineering Porto, Portugal 0009-0001-1793-2328
Informatics Engineering Porto, Portugal 0009-0009-2697-9898
Luı́s Ribeiro Polytechnic of Porto - School of Engineering
Filipe Duarte Polytechnic of Porto - School of Engineering
Informatics Engineering Porto, Portugal 0009-0002-7094-9978
Informatics Engineering Porto, Portugal 0009-0004-0245-6826
Abstract—This paper analyzes the security of the Message Queuing Telemetry Transport (MQTT) protocol in the context of the Internet of Things (IoT). The main objective consists of identifying vulnerabilities and proposing security improvements. Adopting a hybrid methodology, a theoretical review was combined with an experimental demonstration in a simulated Smart Home environment. Eavesdropping, Tampering, Denial of Service (DoS), and Brute Force attacks were executed and analyzed. The results evidenced critical risks due to the absence of robust encryption and authentication. Finally, mitigation strategies and best practices are proposed to strengthen MQTT implementations. Index Terms—MQTT, IoT Security, Cybersecurity, Eavesdropping, DoS, Tampering
I. I NTRODUCTION Nowadays, most everyday devices are connected to the internet due to the production of cheap chips and high-bandwidth telecommunications. This allows millions of devices to have their data collected through sensors, processed, and used to generate intelligent actions [1]. This concept is named the Internet of Things (IoT). Examples of IoT devices include sensors, cameras, lightbulbs, and connected vehicles. These devices can be used in applications such as smart homes, smart cities, and industrial environments. With this inevitable adoption by millions of users worldwide, a new attack surface emerges, as malicious actors focus on the valuable assets of these users [2]. Due to their nature, these devices share common characteristics that lead to severe threats [3]: • Limited Hardware: IoT devices are often meant to be low-energy, meaning they are very simple and lack robust resources. This raises security issues, as the devices are unable to employ sophisticated methods against cyberattacks.
Diverse Communication Technologies: In a distributed system, devices may use varying communication technologies depending on their needs (e.g., Wi-Fi, Bluetooth, Zigbee, LoRaWAN). Each technology has its own security mechanisms and vulnerabilities, making it complex to secure such a vast system entirely. • Vulnerable Components: Due to their simplistic components, these devices are regularly susceptible to attacks. Given that these devices operate under severe power and processing restrictions, it is crucial that the communication protocols used are lightweight and efficient. In this context, the Message Queuing Telemetry Transport (MQTT) protocol stands out. Designed for Machine-to-Machine (M2M) communication, it is optimized for limited bandwidth networks and low-resource devices [4]. The main objective of this work is to perform a security analysis of the MQTT protocol to identify vulnerabilities and propose improvements. This includes identifying known and potential vulnerabilities through theoretical review, practically demonstrating exploits in a controlled environment, and proposing mitigation strategies and best practices. •
II. MQTT P ROTOCOL : F UNDAMENTAL C ONCEPTS The emergence of distributed systems highlighted the need for more flexible data-sharing mechanisms, as the traditional client/server paradigm proved too rigid for dynamic and heterogeneous networks [5], [6]. A. The Publisher/Subscriber Paradigm To address the limitations of the client/server model, the Publisher/Subscriber paradigm was introduced [7]. In this model, nodes no longer depend directly on each other; instead, they rely on middleware to route the data they are
interested in. A producer generates and publishes data, while a subscriber consumes only the data relevant to its interests. This mechanism of mediation ensures effective decoupling, where producers and consumers interact without requiring simultaneous connections or mutual knowledge. Depending on the system, the routing can be content-based, type-based, or topic-based [8]. B. Architecture and Operation MQTT, introduced in 1999, is a centralized, topic-based protocol [9]. It relies on a central server called a broker to manage topics, subscribers, and publishers. Key operational mechanisms include: • Topics and Wildcards: Topics function as channels for messages and follow a hierarchical structure (e.g., /temperature/room). Subscriptions can utilize wildcards: “+” substitutes exactly one level, while “#” encompasses all subsequent sub-levels. • Quality of Service (QoS): MQTT offers three levels of delivery guarantees. QoS 0 (At Most Once) is a fireand-forget approach. QoS 1 (At Least Once) guarantees delivery but may result in duplicates. QoS 2 (Exactly Once) ensures no duplicates but introduces higher latency. • Retained Messages and Last Will: Publishers can mark a message to be retained by the broker, sending it automatically to new subscribers. The Last Will mechanism allows a client to configure a message that the broker will publish automatically if the client disconnects abruptly. • Session Persistence: Clients can connect with a clean session flag. If disabled, the broker maintains persistent session information, delivering pending QoS 1 and QoS 2 messages when the client reconnects.
B. Transport Layer Security To mitigate plain-text transmission vulnerabilities, SSL/TLS is heavily recommended. TLS establishes a secure communication channel through an asymmetric cryptographic handshake, followed by symmetric encryption for continuous data transmission. While highly effective, TLS introduces significant computational overhead, which may not be viable for extremely resource-constrained devices. IV. V ULNERABILITY A NALYSIS By default, MQTT transmits messages in plain text without encryption. This allows attackers to easily intercept sensitive data. Furthermore, brokers with default configurations often lack ACLs, allowing anonymous connections. A. Known Vulnerabilities and Exploits A large-scale analysis identified approximately 425,000 public MQTT backends, of which 59% allowed direct connections without any trust relationship [13]. Many allowed wildcard subscriptions, granting attackers passive access to telemetry, location, health, and firmware update data. Furthermore, 99.84% of analyzed MQTT/XMPP backends used insecure transport methods. Several Common Vulnerabilities and Exposures (CVEs) have also been reported. For instance, CVE-2019-9749 exposes Fluent bit brokers to Distributed Denial of Service (DDoS) attacks [14], while CVE-2018-19417 highlights a stack-based overflow in Contiki-NG servers allowing remote code execution [15]. Modern attack models have also demonstrated Man-in-the-Middle (MiTM) capabilities using adversarial machine learning to evade anomaly detection [16]–[18].
C. Implementations and Use Cases
B. Risk Matrix Assessment
MQTT represents a protocol specification rather than a single implementation. Widely used brokers include Eclipse Mosquitto, EMQX, HiveMQ, and VerneMQ [10], [11]. Clientside libraries, such as Eclipse Paho, exist for multiple programming languages. Due to its lightweight architecture, MQTT is heavily utilized in smart homes (domotics), industrial settings (exchanging data between PLCs and sensors), and smart city infrastructures (traffic and environmental monitoring).
Based on the protocol’s design and current deployment practices, several key threats emerge: • Unauthorized Access (Critical Risk): Permissive anonymous connections and missing ACLs enable widescale data harvesting facilitated by topic wildcards. • Denial of Service (Critical Risk): Brokers are vulnerable to malformed packet parsing and act as a single point of failure in standard MQTT deployments. • Eavesdropping (High Risk): Highly probable due to default plain-text transport and low TLS adoption rates among IoT developers. • Data Manipulation / Tampering (High Risk): The absence of strong application-layer authentication allows active remote attackers to intercept and alter control messages.
III. S ECURITY M ECHANISMS MQTT was designed to be lightweight, resulting in relatively limited native security mechanisms. Communication protection is generally ensured across external layers [12]. A. Authentication and Authorization The protocol supports authentication via Client Identifiers, X.509 Certificates, or standard username and password credentials. However, without external encryption, usernames and passwords are transmitted in plain text. Authorization is typically managed by the broker using Access Control Lists (ACLs), which define the topics and operations (publish/subscribe) permitted for each client.
V. E XPERIMENTAL E NVIRONMENT AND D EMONSTRATION A simulated Smart Home scenario was created to test these vulnerabilities. The environment was executed locally using Docker, containing distinct containers for communication, visualization, simulation, and attack scripts.
The core communication relied on the Eclipse Mosquitto broker (port 1883), chosen for its lightweight nature and maturity in edge scenarios [10], [11]. A Node-RED instance (port 1880) provided the visualization dashboard. As illustrated in Fig. 1, an Edge Node acted as the operation’s brain, triggering an Air Conditioner (AC) if the temperature exceeded 24°C, and turning on a light if a door sensor registered as open.
Fig. 2. Diagram illustrating the Man-in-the-Middle (MiTM) tampering attack via a fake Mosquitto broker.
Fig. 1. Architecture diagram of the simulated Smart Home environment.
A. Eavesdropping The scenario was configured without TLS, meaning data traversed the network in plain text. An attacker on the same Docker network used a custom Python script, connected as an anonymous client, and subscribed to the # wildcard. The script successfully captured sensitive plain-text payloads, including {"temperature": 23.4} and {"door_state": "open"}. By logging this data into a CSV file, an attacker could study behavioral trends to determine when the house is empty.
an average of 6 to 8 ms to over 60 seconds during the attack, effectively denying service to legitimate smart home components. Table I illustrates this severe service degradation by showing the recorded latency immediately before and during the attack. TABLE I E ND - TO -E ND M ESSAGE L ATENCY B EFORE AND D URING D O S ATTACK Message Seq. 1 5 10 11 12 15 20 24
Network State Normal Normal Normal DoS Initiated DoS Active DoS Active DoS Active DoS Active
Recorded Latency (s) 0.007 0.008 0.011 67.347 66.350 63.351 58.350 54.348
B. Tampering
D. Credential Brute Force
This attack utilized ARP Spoofing to execute a Man-in-theMiddle (MiTM) intercept. Using the bettercap tool within a Kali Linux container, the attacker flooded the network with Gratuitous ARP messages [19], [20]. The network was tricked into routing the temperature sensor’s traffic to a malicious proxy listening on port 1883, as shown in Fig. 2. The proxy adulterated the payload while carefully maintaining the original byte size to avoid corrupting the MQTT Remaining Length header. Consequently, the Node-RED dashboard displayed a tampered temperature of 999.9°C instead of the legitimate 24.56°C.
The Mosquitto broker does not natively limit login attempts or enforce password complexity. An attacker script systematically attempted authentication combinations. Searching a 36character space (lowercase letters and numbers), a 4-character password (1234) was cracked in roughly 3,760 seconds (about one hour). Because the time requirement grows exponentially, a 5-character password would take an estimated 22 days. Furthermore, a timing attack was attempted, but Mosquitto’s consistent response times prevented the extraction of sensitive temporal data.
C. Denial of Service To test availability, an open-source tool named MQTT Stresser [21] was deployed. The tool connected 3,000 concurrent clients, attempting to publish 100,000 messages with QoS 1. While the Mosquitto broker did not crash, service was severely degraded. A custom Python script evaluating end-to-end latency showed that message delays spiked from
VI. M ITIGATION AND B EST P RACTICES A. Eavesdropping and Tampering Mitigation Data must be protected via encryption. TLS ensures data confidentiality and integrity, preventing network-level eavesdropping and MiTM attacks [22]. However, for highly constrained devices where TLS overhead is too heavy, applicationlayer encryption should be used [23].
Recent studies propose utilizing Physical Unclonable Functions (PUFs) to generate unpredictable, dynamic symmetric keys without permanent storage [24]. Alternatively, lightweight software-oriented cryptographic algorithms like PRIDE and LEA offer high efficiency with low ROM/RAM consumption [25]. To ensure integrity without TLS, Message Authentication Codes (MACs) or Hash-based MACs (HMACs) must be appended to application payloads [26], [27]. B. Denial of Service Mitigation Application-layer DoS can be mitigated by enforcing strict authentication and ACL privileges. Brokers like Mosquitto should also be configured with strict resource limits, such as max_packet_size, message_size_limit, and max_inflight_bytes [28]. At the network layer, firewalls, IP whitelisting, and Network Access Control (NAC) technologies should be implemented [29]. Intrusion Detection Systems utilizing Signature-based Detection [30] or Machine Learning models (such as Random Forest or Support Vector Machines) can accurately identify and filter malicious MQTT traffic [31]. C. Brute Force Mitigation Strict password policies (minimum length, complex characters) must be enforced. To counter the lack of native ratelimiting, external security tools like Fail2ban can be used to analyze log files and temporarily block IP addresses exhibiting suspicious, repeated login failures [32]. VII. C ONCLUSION In its default form, MQTT lacks robust security mechanisms, leaving it highly vulnerable to a variety of exploits, particularly in environments with constrained resources. The simulated smart home scenario successfully demonstrated severe operational risks, validating vulnerabilities regarding broker availability (DoS), data integrity (Tampering), confidentiality (Eavesdropping), and weak authentication (Brute Force). All proposed attacks succeeded in compromising the system. While comprehensive mitigations (such as transport and application-layer encryption, robust ACLs, and active network monitoring) were proposed in detail theoretically, it is important to note a limitation of this work: these defensive measures were not practically implemented and tested against the simulated attacks in the lab environment. Given the results observed in this analysis, it would be highly relevant for future work to conduct similar practical security evaluations on other communication protocols frequently utilized in edge and IoT contexts, such as the Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (CoAP), Data Distribution Service (DDS), and Apache Kafka. R EFERENCES [1] Amazon Web Services (AWS), “O que é iot (internet das coisas)?” https: //aws.amazon.com/pt/what-is/iot/, accessed: Oct. 11, 2025. [2] C. Henke, “What is iot security? risks, examples, and solutions,” https: //www.emnify.com/blog/iot-security, 2025, accessed: Oct. 11, 2025.
[3] Fortinet, “What is iot device vulnerability?” https://www.fortinet.com/ resources/cyberglossary/iot-device-vulnerabilities, accessed: Oct. 11, 2025. [4] R. Mohanan, “Survey of mqtt protocol for the internet of things,” International Journal of Research in Engineering, Science and Management, vol. 1, no. 9, pp. 385–389, Sep 2018. [5] O. Ajayi, A. Bagula, J. Bode, and M. Damon, “A comparison of publish subscribe and client server models for streaming iot telemetry data,” in Emerging Technologies for Developing Countries, M. Masinde and A. Bagula, Eds. Cham, Switzerland: Springer, 2023, vol. 503, pp. 123–137. [6] M. Nast, H. Raddatz, B. Rother, F. Golatowski, and D. Timmermann, “A survey and comparison of publish/subscribe protocols for the industrial internet of things (iiot),” in Proc. 12th Int. Conf. Internet of Things (IoT ’22), 2023, pp. 193–200. [7] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of publish/subscribe,” ACM Computing Surveys, vol. 35, no. 2, pp. 114–131, Jun 2003. [8] H. Shen, “Content-based publish/subscribe systems,” University of Arkansas, Fayetteville, AR, USA, Tech. Rep., 2025. [9] B. M. M. El-Basioni, “A conceptual modeling approach of mqtt for iot-based systems,” Journal of Electrical Systems and Information Technology, vol. 11, no. 62, 2024. [10] N. Cresswell, “Mqtt at the edge, which do you choose?” Portainer.io. https://www.portainer.io/blog/best-mqtt-broker, Feb 2025, accessed: Feb. 20, 2025. [11] L. Dallinger, “Mosquitto vs hivemq – an honest comparison for iot teams,” Cedalo. https://cedalo.com/blog/ mosquitto-vs-hivemq-an-honest-comparison-for-iot-teams/, Oct 2025, accessed: Oct. 31, 2025. [12] HiveMQ, “Introducing the mqtt security fundamentals,” https: //www.hivemq.com/blog/introducing-the-mqtt-security-fundamentals/, accessed: Dec. 23, 2025. [13] C. Tagliaro, M. Komsic, A. Continella, K. Borgolte, and M. Lindorfer, “Large-scale security analysis of real-world backend deployments speaking iot-focused protocols,” in Proc. 27th Int. Symp. on Research in Attacks, Intrusions and Defenses (RAID), Sep 2024, pp. 561–578. [14] National Institute of Standards and Technology (NIST), “Cve-20199749,” National Vulnerability Database (NVD). https://nvd.nist.gov/ vuln/detail/CVE-2019-9749. [15] ——, “Cve-2018-19417,” National Vulnerability Database (NVD). https: //nvd.nist.gov/vuln/detail/CVE-2018-19417. [16] H. Wong and T. Luo, “Man-in-the-middle attacks on mqtt-based iot using bert based adversarial message generation,” https://arxiv.org/abs/ 2009.02235, 2020. [17] F. Chen, Y. Huo, J. Zhu, and D. Fan, “A review on the study on mqtt security challenge,” in 2020 IEEE International Conference on Smart Cloud (SmartCloud), Washington, DC, USA, 2020, pp. 128–133. [18] S. U. A. Laghari, W. Li, S. Manickam, P. Nanda, A. K. Al-Ani, and S. Karuppayah, “Securing mqtt ecosystem: Exploring vulnerabilities, mitigations, and future trajectories,” IEEE Access, vol. 12, pp. 139 273– 139 289, 2024. [19] Fortinet, “Address resolution protocol (arp): Resolving network address conflicts,” https://www.fortinet.com/resources/cyberglossary/ what-is-arp, accessed: Jan. 04, 2026. [20] A. Viescinski and M. Aibin, “How does gratuitous arp work?” Baeldung. https://www.baeldung.com/cs/gratuitous-arp, Jan 2026, accessed: Jan. 04, 2026. [21] inovex, “mqtt-stresser,” GitHub repository. https://github.com/inovex/ mqtt-stresser, 2020. [22] S. S. Alharbi, D. Bell, and W. Awad, “Application layer security: Mqtt perspective with tls implementation and analysis,” in Proc. Int. Conf. IT Innovation and Knowledge Discovery (ITIKD), Manama, Bahrain, 2025, pp. 1–14. [23] A. R. Alkhafajee, A. M. A. Al-muqarm, Z. R. Mohammed, and A. H. Alwan, “Security and performance analysis of mqtt protocol with tls in iot networks,” in Proc. 4th Int. Iraqi Conf. Eng. Technol. and Their Appl. (IICETA), Najaf, Iraq, 2021, pp. 206–212. [24] X. Gong, T. Kou, and Y. Li, “Enhancing mqtt-sn security with a lightweight puf-based authentication and encrypted channel establishment scheme,” Symmetry, vol. 16, no. 10, p. 1282, 2024. [25] P. S. Suryateja and K. V. Rao, “A survey on lightweight cryptographic algorithms in iot,” Cybernetics and Information Technologies, vol. 24, no. 1, pp. 21–34, 2024.
[26] A. J. Hintaw, S. Manickam, M. F. Aboalmaaly, and S. Karuppayah, “Mqtt vulnerabilities, attack vectors and solutions in the internet of things (iot),” IETE Journal of Research, vol. 69, no. 6, pp. 3368–3397, 2023. [27] C. Gao, X. Xi, and C. Zhang, “Security model design and formal verification of mqtt protocol,” Discovery Applied Sciences, vol. 7, p. 1227, 2025. [28] U. Morelli, I. Vaccari, S. Ranise, and E. Cambiaso, “Dos attacks in available mqtt implementations: Investigating the impact on brokers and devices, and supported anti-dos protections,” in Proc. 16th Int. Conf. Availability, Reliability and Security (ARES ’21), 2021, pp. 1–9, art. no. 82. [29] M. T., Y. Xiao, G. Sun, and W. Jiang, “A survey of distributed denialof-service attack, prevention, and mitigation techniques,” International Journal of Distributed Sensor Networks, vol. 13, no. 12, 2017. [30] R. Bronte, H. Shahriar, and H. M. Haddad, “A signature-based intrusion detection system for web applications based on genetic algorithm,” in Proc. 9th Int. Conf. Security of Information and Networks (SIN ’16), 2016, pp. 32–39. [31] D. Dikii, S. Arustamov, and A. Grishentsev, “Dos attacks detection in mqtt networks,” Indonesian Journal of Electrical Engineering and Computer Science, vol. 21, no. 1, pp. 601–608, Jan 2021. [32] Fail2Ban, “fail2ban,” GitHub repository. https://github.com/fail2ban/ fail2ban, 2012.