CVE-2026-44639: NanoMQ MQTT Broker DOS Vulnerability

CVE-2026-44639 Overview

CVE-2026-44639 is an algorithmic complexity vulnerability [CWE-407] in NanoMQ, an open-source MQTT broker. Versions prior to 0.24.14 contain an inefficient property decoder in nng/src/supplemental/mqtt/mqtt_codec.c. The property_append() function walks the entire linked list for each property added by decode_buf_properties(). A remote unauthenticated attacker can send a single MQTT v5 PUBLISH or SUBSCRIBE packet containing many User Properties. This triggers O(N²) linked-list insertion work and consumes CPU on the broker. Repeated packets can sustain the denial-of-service condition and make the broker unresponsive to legitimate clients.

Critical Impact
A remote unauthenticated client can render the NanoMQ broker unresponsive by sending crafted MQTT v5 packets containing large numbers of User Properties.

Affected Products

NanoMQ broker versions prior to 0.24.14
Deployments processing MQTT v5 PUBLISH packets from untrusted clients
Deployments processing MQTT v5 SUBSCRIBE packets from untrusted clients

Discovery Timeline

2026-09-18 - CVE-2026-44639 published to the National Vulnerability Database (NVD)
2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-44639

Vulnerability Analysis

The defect resides in the MQTT v5 property decoding path of NanoMQ. When decode_buf_properties() parses incoming property blocks, it invokes property_append() to attach each parsed property to a singly-linked list. Because property_append() traverses the list from head to tail on every insertion, the total decode cost grows quadratically with the number of properties in a single packet.

MQTT v5 permits repeated User Properties within packet property blocks. An attacker can therefore stuff a single valid packet with thousands of User Property entries, forcing the broker to perform millions of pointer traversals inside the decode routine. The broker's event loop stalls while decoding, blocking service to legitimate MQTT clients.

The issue is classified under [CWE-407: Inefficient Algorithmic Complexity]. Exploitation requires no authentication and no user interaction. Attack complexity is elevated because the attacker must generate sufficient packet volume to sustain CPU pressure against the broker.

Root Cause

The root cause is the absence of a tail pointer on the property list in mqtt_codec.c. Each call to property_append() re-walks the full list to find the insertion point, resulting in O(N²) complexity for decoding a property block containing N entries.

Attack Vector

A remote attacker connects to the broker over the MQTT protocol and issues a PUBLISH or SUBSCRIBE control packet whose variable-header property section contains a large number of User Property key-value pairs. Because no authentication is required to reach the decoder, any network-reachable broker is exposed. Repeated packets amplify the impact and sustain the denial of service.

// Patch excerpt from src/supplemental/mqtt/mqtt_codec.c
// Adds a tail pointer to eliminate the O(N^2) walk during property decoding.
 		return -1;
 	}
 	property *list = property_alloc();
+	property *tail = list;
 
 	for (property *p = src->next; p != NULL; p = p->next) {
 		property_type_enum type = property_get_value_type(p->id);
// Source: https://github.com/nanomq/NanoNNG/commit/91bd4c7f45f945a3f5f0e37c459157dc7c277a07

Detection Methods for CVE-2026-44639

Indicators of Compromise

Sustained high CPU utilization by the nanomq broker process without a corresponding rise in legitimate client throughput.
MQTT v5 PUBLISH or SUBSCRIBE packets from a single source containing an unusually large property section or repeated User Property entries.
Legitimate MQTT clients reporting timeouts, dropped connections, or KeepAlive failures against a previously stable broker.

Detection Strategies

Inspect MQTT v5 traffic at the network layer for packets whose property length field is disproportionate to typical application payloads.
Correlate broker CPU spikes with inbound packet metadata to identify sources sending anomalously large property blocks.
Enable verbose broker logging during triage to capture packet size distributions and originating client identifiers.

Monitoring Recommendations

Baseline normal MQTT packet sizes and property counts for each broker, then alert on statistical outliers.
Track per-source connection and packet rates to identify clients driving disproportionate broker CPU load.
Monitor process-level CPU and event-loop latency metrics on broker hosts and alert on sustained saturation.

How to Mitigate CVE-2026-44639

Immediate Actions Required

Upgrade NanoMQ to version 0.24.14 or later, which contains the corrected property decoder.
Restrict broker exposure to trusted networks using firewall rules or a reverse proxy until the upgrade is applied.
Enforce MQTT authentication and access control lists to prevent anonymous clients from submitting PUBLISH or SUBSCRIBE packets.

Patch Information

The fix is included in NanoMQ Release v0.24.14 and tracked in GitHub Pull Request #1508. The upstream code change is documented in the GitHub Commit Update. Additional context is available in the GitHub Security Advisory GHSA-6mwg-445v-2qrv. The patch adds a tail pointer to the property list, converting insertion cost from O(N) per call to O(1).

Workarounds

Place a rate-limiting or packet-size-limiting proxy in front of the broker to reject oversized MQTT property blocks.
Terminate MQTT connections at a TLS-authenticating gateway that requires client certificates before packets reach the broker.
Configure network ingress rules to permit MQTT connectivity only from known, trusted client subnets.

bash

# Example: restrict MQTT (port 1883) access to a trusted subnet using iptables
iptables -A INPUT -p tcp --dport 1883 -s 10.10.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP

# Verify the running NanoMQ version is 0.24.14 or later
nanomq --version