CVE-2026-47275 in NanoMQ
Summary
by MITRE • 07/20/2026
In nanomq versions 0.24.11 and earlier, a NULL pointer dereference in `nni_mqttv5_msg_decode_connect()` allows a malicious MQTT broker to crash any connecting NanoMQ MQTTv5 client (including bridge mode) with a single packet, causing remote denial of service via SIGSEGV. In `nni_mqttv5_msg_decode_connect()` (`mqtt_codec.c:1863`), the code iterates over CONNECT properties using variable `prop` when it should use `will_prop`. When a CONNECT packet has no connect-level properties (`prop == NULL`) but has will properties (`will_prop != NULL`), dereferencing `prop->next` causes SIGSEGV at address `0x38` (NULL + `offsetof(property, next)`).
This affects both `nanomq_cli` and **NanoMQ bridge mode** (Core component), as both use the same `mqtt_client.c` receive path. This can lead to remote DoS if a malicious MQTT broker can crash the client process with a single 35-byte packet and persistent DoS if auto-reconnect causes infinite crash loop.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability described in this CVE represents a critical NULL pointer dereference flaw within the NanoMQ MQTTv5 implementation that fundamentally compromises system stability and availability. This issue exists in nanomq versions 0.24.11 and earlier, where the nni_mqttv5_msg_decode_connect() function in mqtt_codec.c at line 1863 contains a logical error that leads to segmentation faults during MQTT client processing. The flaw manifests when a CONNECT packet lacks connect-level properties but includes will properties, creating a scenario where the code incorrectly iterates over the wrong property variable.
The technical implementation error stems from a variable naming confusion within the MQTTv5 message decoding logic where the code uses 'prop' instead of 'will_prop' during iteration. This specific bug occurs in the context of MQTT protocol handling when processing CONNECT packets, which are fundamental to establishing MQTT client connections. The vulnerability operates through a classic null pointer dereference pattern where prop->next is accessed when prop is NULL, resulting in a SIGSEGV signal at address 0x38 which corresponds to NULL plus the offset of the next field within the property structure.
This flaw impacts both the nanomq_cli command-line interface and NanoMQ bridge mode functionality since they share the same core mqtt_client.c receive path processing logic. The operational impact extends beyond simple service disruption as it enables remote denial of service attacks that can be executed with a single 35-byte malicious MQTT packet. The vulnerability creates an immediate crash condition that affects any connecting NanoMQ client regardless of its operational mode, making it particularly dangerous in production environments where client stability is paramount.
The security implications are severe given that this vulnerability can be exploited remotely by malicious MQTT brokers to cause persistent denial of service conditions. When combined with auto-reconnect functionality, the vulnerability creates an infinite crash loop scenario that can completely disable client operations until manual intervention occurs. This behavior aligns with ATT&CK technique T1499.004 for network denial of service and represents a classic example of a memory corruption vulnerability that can be exploited through improper input validation.
From a CWE perspective, this vulnerability maps to CWE-476 NULL Pointer Dereference, which specifically addresses the scenario where code attempts to access members of a null pointer. The weakness occurs due to inadequate null checking before dereferencing pointers in property handling logic. The issue also demonstrates poor defensive programming practices that fail to validate property structure initialization before accessing linked list elements. Organizations using NanoMQ in production environments should consider implementing immediate mitigations including version updates, network segmentation to prevent access from untrusted MQTT brokers, and monitoring for unusual client crash patterns.
The vulnerability highlights the importance of proper input validation in protocol implementations and demonstrates how seemingly minor coding errors can create significant security risks. Given that MQTT is widely used in IoT and industrial applications, this flaw could potentially impact critical infrastructure systems where continuous availability is essential. The fix requires correcting the variable reference in the property iteration logic to ensure that will properties are properly handled when connect-level properties are absent. This remediation should be prioritized at the highest level as it represents a direct threat to system availability and can be exploited without authentication.