NanoMQ MQTT Broker Heap-Use-After-Free Vulnerability in MQTT Bridge Client Component

Vulnerability

A Heap-Use-After-Free vulnerability has been identified in the NanoMQ MQTT Broker, specifically in versions prior to 0.24.5. This vulnerability occurs within the MQTT bridge client component, which is implemented using the NanoNNG library. The issue arises when NanoMQ bridges connections to a remote MQTT broker. A malicious broker can exploit this by sending a sequence of malformed packets immediately after establishing a connection, leading to a crash (Denial of Service) or potential memory corruption. The vulnerability is caused by improper handling of the MQTT protocol, allowing exploitation through crafted CONNACK packets.

Impact

Exploitation of this vulnerability can cause a Denial-of-Service condition by crashing the NanoMQ broker. Additionally, it can lead to memory corruption, which may have further implications depending on how the corrupted memory is handled.

Reproduction

To reproduce this vulnerability, set up a NanoMQ broker version prior to 0.24.5 and configure it to bridge connections to a remote MQTT broker. Once the connection is established, the remote broker should send a malformed packet sequence. This can be done by manipulating the MQTT protocol to send invalid data immediately after the CONNACK packet is acknowledged, causing the NanoMQ broker to crash or experience memory corruption.

Remediation

Users can upgrade to NanoMQ version 0.24.5 or later, where this vulnerability has been patched. The patch enforces stricter adherence to the MQTT protocol by ensuring that the CONNACK packet is always the first one processed, preventing the state confusion that led to the Heap-Use-After-Free vulnerability. As an additional step, validate the remote broker before establishing a bridge connection.

Added: Jan 1, 2026, 3:17 PM
Updated: Jan 1, 2026, 3:17 PM

Vulnerability Rating

Custom Algorithm
spread
0.3
impact
2.5
exploitability
5.0
remediation
7.9
relevance
1.8
threat
4.8
urgency
2.9
incentive
1.7

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.