NanoMQ is an MQTT broker. Prior to 0.24.14, NanoMQ's broker-side MQTT v5 nmqsubinfodecode() function in nng/src/sp/protocol/mqtt/mqttparser.c reuses lenofvarint from the outer Properties Length while parsing each SUBSCRIPTIONIDENTIFIER. A remote client can send a SUBSCRIBE packet with a multi-byte Properties Length and repeated subscription identifiers, causing getvarinteger() to begin at an incorrect offset and read beyond the heap message buffer. The flaw is reachable through the broker receive path and can crash the broker, while the separately reported topic-option off-by-one occurs later and is not this vulnerability. This issue is fixed in version 0.24.14.

NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. Prior to 0.24.14, aio->provdata is stored as nniquicconn during dialing, but read as exquicconn during dialer close. This type confusion causes invalid object interpretation and leads to close-path hang/crash behavior. This vulnerability is fixed in 0.24.14.

NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. Prior to version 0.24.10, in NanoMQ's webhookinproc.c, the hookworkcb() function processes nng messages by parsing the message body with cJSONParse(body). The body is obtained from nngmsgbody(msg), which is a binary buffer without a guaranteed null terminator. This leads to an out-of-bounds read (OOB read) as cJSONParse reads until it finds a \0, potentially accessing memory beyond the allocated buffer (e.g., nngmsg metadata or adjacent heap/stack). The issue is often masked by nng's allocation padding (extra 32 bytes of zeros for non-power-of-two sizes <1024 or non-aligned). The overflow is reliably triggered when the JSON payload length is a power-of-two >=1024 (no padding added). This issue has been patched in version 0.24.10.