CVE-2026-32134: NanoMQ MQTT Broker DoS Vulnerability

CVE-2026-32134 Overview

CVE-2026-32134 is a NULL pointer dereference vulnerability [CWE-476] in NanoMQ MQTT Broker, an edge messaging platform widely deployed in IoT and edge computing environments. The flaw affects versions 0.24.10 and below. Under high-concurrency reconnect traffic carrying a reconnect-collision payload, the broker crashes during MQTT session resumption for clients connecting with clean_start=0. The transport callback tcptran_pipe_peer() iterates cpipe->subinfol without verifying the pointer is non-NULL, leading to a process crash. Remote unauthenticated attackers can trigger this condition. The maintainers fixed the issue in version 0.24.11.

Critical Impact

Remote unauthenticated attackers can crash the NanoMQ broker process by inducing a reconnect race, disrupting MQTT message delivery across all connected edge clients.

Affected Products

• NanoMQ MQTT Broker versions 0.24.10 and below
• NanoNNG transport layer (broker_tcp.c and broker_tls.c)
• Edge deployments relying on persistent MQTT sessions with clean_start=0

Discovery Timeline

• 2026-05-19 - CVE-2026-32134 published to NVD
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-32134

Vulnerability Analysis

The vulnerability resides in the NanoNNG MQTT transport layer, specifically the tcptran_pipe_peer() callback registered as the pipe peer handler. When a client reconnects with clean_start=0, the broker attempts to restore the prior session by copying subscription metadata from the cached old pipe (cpipe) to the new reconnecting pipe (npipe).

The callback acquires p->mtx and then iterates cpipe->subinfol via NNI_LIST_FOREACH. The pre-patch code only checked whether cpipe->subinfol was non-NULL. It did not verify the state of npipe->subinfol, the destination list used by the session restore path.

Under concurrent reconnect traffic, a race condition allows the cached pipe's subinfol to be freed and set to NULL after the initial check but before iteration completes on the target pipe. The dereference of the freed or NULL list head produces a segmentation fault, terminating the broker process.

Root Cause

The root cause is missing NULL pointer validation during MQTT session resumption [CWE-476]. The session restore logic assumes both source and destination subscription lists remain valid for the duration of the copy operation. Reconnect-collision traffic invalidates this assumption by freeing list state on a parallel pipe lifecycle.

Attack Vector

An unauthenticated remote attacker establishes many MQTT connections using the same client identifier with clean_start=0. By rapidly disconnecting and reconnecting these sessions in parallel, the attacker forces concurrent execution of session resumption paths. The race window allows subinfol to transition to NULL while tcptran_pipe_peer() is mid-iteration, crashing the broker.

// Patch from src/sp/transport/mqtt/broker_tcp.c
// and src/sp/transport/mqtts/broker_tls.c
npipe = (nni_pipe *) cpipe->tpipe; // target pipe

nni_mtx_lock(&p->mtx);
-if (cpipe->subinfol != NULL) {
+if (cpipe->subinfol != NULL && npipe->subinfol != NULL) {
    NNI_LIST_FOREACH(cpipe->subinfol, info) {
        if (!info) {
            log_error("got error topic from subinfol!");

Source: NanoNNG commit 522ec62. The patch adds a NULL check on npipe->subinfol before iterating, preventing the dereference when the target pipe's subscription list has been freed.

Detection Methods for CVE-2026-32134

Indicators of Compromise

• Unexpected NanoMQ broker process crashes or segmentation faults in system logs
• High volume of MQTT CONNECT packets reusing identical client identifiers with clean_start=0
• Bursts of TCP connections to broker ports (default 1883 or 8883 for TLS) followed by rapid disconnects
• Core dumps showing crash inside tcptran_pipe_peer() or NNI_LIST_FOREACH macros

Detection Strategies

• Monitor broker process uptime and restart counts; correlate with MQTT connection logs
• Alert on repeated CONNECT/DISCONNECT cycles from the same source IP within short windows
• Inspect nanomq logs for got error topic from subinfol! messages preceding crashes

Monitoring Recommendations

• Track MQTT connection rate per source IP and per client identifier
• Enable broker-side audit logging for session resumption events
• Forward NanoMQ logs and crash telemetry to a centralized SIEM for correlation across edge nodes

How to Mitigate CVE-2026-32134

Immediate Actions Required

• Upgrade NanoMQ to version 0.24.11 or later on all broker instances
• Restrict broker exposure to trusted networks via firewall rules until patching is complete
• Enable authentication and TLS to limit who can initiate reconnect traffic

Patch Information

The fix is available in NanoMQ release 0.24.11. The patch adds a NULL check on npipe->subinfol in both the TCP and TLS transport callbacks. See the GitHub Security Advisory GHSA-q36f-83mh-pcv2 and the upstream issue discussion for additional context.

Workarounds

• Rate-limit incoming MQTT connections per source IP at the network edge
• Require client authentication to prevent anonymous reconnect-collision traffic
• Deploy a reverse proxy or load balancer that throttles rapid reconnects from the same client identifier

# Upgrade NanoMQ to the patched release
git clone -b 0.24.11 https://github.com/nanomq/nanomq.git
cd nanomq
mkdir build && cd build
cmake -G Ninja ..
ninja install

# Verify version
nanomq --version