CVE-2023-28366 in Mosquitto
Summary
by MITRE • 09/01/2023
The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/27/2025
The vulnerability CVE-2023-28366 affects Eclipse Mosquitto broker versions 1.3.2 through 2.x before 2.0.16, presenting a significant memory leak issue that can be remotely exploited. This flaw exists within the broker's handling of Quality of Service level 2 (QoS 2) message processing, specifically when clients send multiple QoS 2 messages with duplicate message identifiers while failing to respond to PUBREC commands. The vulnerability stems from improper error handling of the EAGAIN return code from the underlying libc send function, creating a condition where memory allocated for message processing is not properly released, leading to progressive memory consumption over time. The attack vector requires a remote client to establish a connection and send specially crafted messages that trigger the memory leak condition, making it particularly dangerous in environments where the broker handles numerous concurrent connections. This vulnerability falls under CWE-401: Improper Release of Memory and aligns with ATT&CK technique T1499.001: Network Denial of Service, as it can lead to system resource exhaustion and service disruption.
The technical implementation of this vulnerability exploits the MQTT protocol's QoS 2 message flow which involves four steps: PUBLISH, PUBREC, PUBREL, and PUBCOMP. When a client sends multiple QoS 2 messages with identical message IDs and subsequently fails to respond to the PUBREC acknowledgments, the broker enters a state where it continuously allocates memory for message tracking without proper cleanup. The EAGAIN error code from libc send indicates that the send operation would block, but the broker's implementation fails to properly handle this condition, causing memory allocation to persist indefinitely. This memory leak occurs because the broker maintains internal data structures for tracking in-flight QoS 2 messages, and when the client does not respond appropriately to PUBREC commands, these structures remain allocated without proper garbage collection. The vulnerability is particularly insidious because it can be triggered with relatively simple client behavior, requiring minimal malicious intent from the attacker.
The operational impact of CVE-2023-28366 extends beyond simple resource exhaustion to potentially compromise the entire broker service availability. As memory consumption increases continuously, the broker may eventually crash or become unresponsive, leading to complete service disruption for all connected clients. In production environments, this vulnerability can be exploited to perform a denial of service attack against MQTT broker infrastructure, particularly affecting IoT deployments where Mosquitto is commonly used as a message broker. The memory leak can accumulate over time, making the attack cumulative rather than immediate, which complicates detection and mitigation efforts. Organizations relying on Mosquitto for critical messaging infrastructure face significant risk, as the vulnerability can be exploited by any remote client with access to the broker, potentially leading to unauthorized service disruption. The vulnerability also represents a potential pathway for more sophisticated attacks that could leverage the resource exhaustion to create additional attack vectors.
Mitigation strategies for CVE-2023-28366 primarily focus on immediate software updates to versions 2.0.16 or later, where the memory leak has been addressed through proper error handling of the EAGAIN condition. Organizations should implement monitoring solutions to detect unusual memory consumption patterns in their Mosquitto brokers, enabling early detection of potential exploitation attempts. Network segmentation and access control measures should be enforced to limit client access and reduce the attack surface, while implementing connection rate limiting can help prevent rapid exploitation. Additionally, security teams should consider implementing intrusion detection systems that can identify suspicious message patterns indicative of this vulnerability being exploited. The fix addresses the root cause by ensuring proper cleanup of memory structures when the EAGAIN error occurs during message transmission, preventing the accumulation of unreleased memory allocations. Organizations should also conduct thorough vulnerability assessments to identify any other potential memory leak conditions within their MQTT infrastructure, as similar patterns may exist in other components of their messaging ecosystem.