NanoMQ CVE-2026-32134

Exploitation requires three concurrent conditions: (1) MQTT clients connecting with clean_start=0 (persistent sessions enabled), which is a client-controlled parameter and not a broker configuration default - any client can request persistent session semantics; (2) high-concurrency reconnect traffic sufficient to create a race condition in the broker's pipe_peer() handler, requiring simultaneous reconnect collisions rather than a single connection attempt; and (3) network access to the NanoMQ MQTT port (TCP 1883, TLS 8883, or WebSocket). The CVSS AC:H vector directly encodes that a race condition timing window must be won, making exploitation probabilistic rather than deterministic. Exploitation is limited by: the requirement to generate sustained concurrent reconnect load (not a single-packet trigger), the absence of code execution impact (crash-only), and the need for clients using persistent session mode. Clean_start=1 deployments are entirely unaffected, as the vulnerable session restoration code path is never invoked.

The CVSS 3.1 score of 5.9 (Medium) reflects real tension between severity signals. AV:N/PR:N/UI:N confirm full remote unauthenticated exposure, while AC:H significantly constrains practical exploitability - the attacker must engineer a precise timing collision during concurrent reconnect handling, which requires sustained load and favorable scheduling outcomes rather than a simple single-packet trigger. The impact is limited entirely to availability (C:N/I:N/A:H), meaning a successful exploit crashes the broker process but achieves no code execution, credential theft, or persistent access. The vulnerability is not listed in CISA KEV, and no EPSS score was provided in the input data. No public exploit code exists beyond the commit diff that documents the fix. SSVC signals are not available in the provided data. For internet-exposed NanoMQ deployments serving IoT edge infrastructure, the risk is real but operationally bounded: a crash causes message broker downtime, which can have significant downstream effects in industrial or embedded systems relying on MQTT for telemetry. For internal or access-controlled deployments, the AC:H requirement and lack of active exploitation make this a patch-cycle rather than emergency priority.

An attacker with network access to a NanoMQ broker's MQTT port floods the broker with rapid reconnect requests using clients configured with clean_start=0, creating concurrent pipe_peer() invocations that race against session cleanup. The race frees npipe->subinfol between the null check on cpipe and the copy operation into npipe, dereferencing the NULL pointer and crashing the broker process. No public exploit code exists beyond the documented commit diff, and the AC:H CVSS vector confirms the attacker must sustain precise concurrency - a brute-force timing approach rather than a deterministic single-packet exploit.