CVE-2026-44639 in NanoMQ
Summary
by MITRE • 09/18/2026
NanoMQ is an MQTT broker. Prior to 0.24.14, NanoMQ's MQTT v5 property decoder in nng/src/supplemental/mqtt/mqtt_codec.c uses property_append() to walk the entire linked list for each property added by decode_buf_properties(). A remote unauthenticated client can supply a PUBLISH or SUBSCRIBE packet containing many User Properties, causing O(N²) linked-list insertion and CPU work that makes the broker unresponsive; repeated packets can sustain the denial of service. This issue is fixed in version 0.24.14.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
NanoMQ serves as a lightweight MQTT broker designed for IoT environments, facilitating message exchange between devices using the Message Queuing Telemetry Transport protocol. A critical performance vulnerability exists within the MQTT v5 property decoder logic located in the source file nng/src/supplemental/mqtt/mqtt_codec.c of versions prior to 0.24.14. The core technical flaw stems from an inefficient algorithmic approach when handling user-defined properties attached to MQTT packets. Specifically, the function decode_buf_properties invokes property_append for each individual property extracted from a packet payload. This append operation is implemented by traversing the entire linked list of existing properties to find the insertion point or end of the chain before adding the new item. Consequently, if an incoming PUBLISH or SUBSCRIBE packet contains N user properties, the broker performs approximately N squared operations to process them, resulting in quadratic time complexity O(N²) for property handling rather than linear time complexity.
This architectural inefficiency creates a significant resource exhaustion vector that can be exploited by remote unauthenticated clients. An attacker can craft malicious MQTT packets containing an excessively large number of user properties and send them repeatedly to the broker. Each packet triggers the inefficient linked-list traversal, consuming disproportionate amounts of CPU cycles relative to the actual data volume. As the processor becomes saturated with these computationally expensive operations, the broker loses its ability to process legitimate traffic or maintain active connections effectively. This leads to a state where the service appears unresponsive, constituting a denial of service condition that disrupts availability for all connected clients and dependent systems relying on real-time telemetry data.
The vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to limit the resources consumed by processing user-controlled input. Furthermore, this exploitation technique is categorized under MITRE ATT&CK T1499, specifically Endpoint Denial of Service via resource exhaustion or flood attacks. The attack vector leverages standard MQTT protocol features in a malicious manner, requiring no authentication credentials due to the nature of how property decoding is handled during packet reception phases that are often accessible before full client authorization checks complete for certain operations or where anonymous access is permitted.
Mitigation strategies primarily involve upgrading NanoMQ to version 0.24.14 or later, which resolves this issue by optimizing the linked-list insertion logic to avoid redundant traversals. In environments where immediate patching is not feasible, network-level controls such as rate limiting on MQTT connections can help mitigate the impact of repeated malicious packets. Additionally, configuring firewalls or intrusion prevention systems to inspect and limit the size of MQTT payloads containing user properties may reduce the effectiveness of this attack vector until a permanent software fix is deployed. Monitoring CPU usage patterns associated with MQTT broker processes can also aid in early detection of such resource exhaustion attempts.