CVE-2026-47275: NanoMQ MQTTv5 Client DoS Vulnerability

CVE-2026-47275 Overview

CVE-2026-47275 is a NULL pointer dereference [CWE-476] in NanoMQ versions 0.24.11 and earlier. The flaw exists in the nni_mqttv5_msg_decode_connect() function within mqtt_codec.c. A malicious MQTT broker can crash any connecting NanoMQ MQTTv5 client, including bridge mode, by sending a single 35-byte packet. The client process terminates via SIGSEGV, producing a remote denial of service condition.

Critical Impact
Auto-reconnect logic can convert a single malicious CONNECT ACK packet into a persistent crash loop, disrupting NanoMQ bridge deployments and any MQTTv5 client connecting to attacker-controlled brokers.

Affected Products

NanoMQ versions 0.24.11 and earlier
nanomq_cli MQTTv5 client
NanoMQ bridge mode (Core component)

Discovery Timeline

2026-07-20 - CVE-2026-47275 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-47275

Vulnerability Analysis

The vulnerability resides in nni_mqttv5_msg_decode_connect() at mqtt_codec.c:1863. The decoder iterates over CONNECT properties using the wrong variable. The code references prop where it should reference will_prop. When a CONNECT packet contains no connect-level properties but includes will properties, prop remains NULL while will_prop holds valid data.

During iteration, the code dereferences prop->next, triggering a segmentation fault at address 0x38. That address corresponds to NULL + offsetof(property, next). The crash occurs before any authentication or session state is established, making exploitation trivial for any broker the client contacts.

Both nanomq_cli and the NanoMQ Core bridge component share the same mqtt_client.c receive path. This shared code path expands the attack surface to production bridge deployments that connect to third-party brokers. The vulnerability is tracked as [CWE-476: NULL Pointer Dereference].

Root Cause

The root cause is a variable naming mistake in property list traversal logic. The decoder was intended to walk the will-properties linked list but references the connect-properties list variable instead. Standard-compliant CONNECT packets that omit connect-level properties expose the flaw.

Attack Vector

Exploitation requires a victim NanoMQ client to initiate an MQTTv5 connection to an attacker-controlled or compromised broker. The broker responds with a crafted 35-byte CONNECT-related packet containing will properties but no connect-level properties. Refer to the GitHub Security Advisory GHSA-52qr-3v49-wmx6 for packet-level detail.

Detection Methods for CVE-2026-47275

Indicators of Compromise

Repeated NanoMQ process crashes with SIGSEGV faulting at address 0x38
Core dumps referencing nni_mqttv5_msg_decode_connect in the call stack
Bridge connection loops where the NanoMQ process restarts immediately after connecting to a specific upstream broker
Sudden loss of MQTT bridge telemetry following configuration of a new broker endpoint

Detection Strategies

Monitor system logs and systemd journal entries for repeated nanomq or nanomq_cli segmentation faults
Inspect packet captures on port 1883 or 8883 for MQTTv5 CONNECT packets containing will properties without connect properties
Audit NanoMQ bridge configurations for outbound connections to untrusted or newly added broker endpoints

Monitoring Recommendations

Alert on process restart frequency exceeding baseline for NanoMQ services
Track kernel dmesg output for segfault entries tied to the NanoMQ binary
Correlate broker endpoint changes with subsequent client stability events

How to Mitigate CVE-2026-47275

Immediate Actions Required

Upgrade NanoMQ to a version later than 0.24.11 once the fixed release is available from the maintainers
Restrict NanoMQ bridge configurations to trusted broker endpoints only
Disable auto-reconnect on client processes that connect to third-party brokers to prevent crash loops

Patch Information

Refer to the NanoMQ GitHub Security Advisory GHSA-52qr-3v49-wmx6 for the authoritative patch reference and fixed version details. The fix corrects the property iteration variable in nni_mqttv5_msg_decode_connect() to use will_prop when processing will properties.

Workarounds

Use TLS with mutual certificate authentication so clients only complete handshakes with verified brokers
Deploy a network policy that limits outbound MQTT connections to an allowlist of approved broker IPs
Run NanoMQ under a process supervisor with rate-limited restarts to blunt crash-loop impact until patching is complete

bash

# Configuration example - restrict bridge to trusted broker with TLS
bridges.mqtt.trusted_broker {
  server = "tls://broker.internal.example.com:8883"
  proto_ver = 5
  tls {
    enable = true
    verify_peer = true
    cacertfile = "/etc/nanomq/ca.crt"
  }
}