CVE-2026-36590: EMQ NanoMQ Denial of Service Vulnerability

CVE-2026-36590 Overview

CVE-2026-36590 is a denial-of-service vulnerability in EMQ NanoMQ version 0.24.9, an open-source MQTT broker used in Internet of Things (IoT) and edge computing deployments. The flaw resides in the nni_qos_db_set function within the broker_tcp.c component. A remote attacker can trigger the condition to disrupt broker availability. Public proof-of-concept research references memory leak behavior, indicating resource exhaustion as the underlying issue.

Critical Impact
Remote attackers can crash or degrade NanoMQ broker instances, interrupting MQTT message delivery across dependent IoT and telemetry systems.

Affected Products

EMQ NanoMQ v0.24.9
broker_tcp.c component containing nni_qos_db_set
Deployments exposing NanoMQ MQTT listeners to untrusted networks

Discovery Timeline

2026-07-15 - CVE-2026-36590 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-36590

Vulnerability Analysis

The vulnerability affects NanoMQ, a lightweight MQTT broker written in C. The defect is located in the nni_qos_db_set function called from the TCP broker path in broker_tcp.c. The referenced research on GitHub characterizes the issue as a memory leak that can be exercised by remote clients. Repeated exploitation exhausts broker memory, ultimately producing a denial of service against subscribers and publishers connected to the broker.

Because MQTT brokers frequently sit at the center of IoT fleets, factory telemetry pipelines, and edge messaging systems, an outage of the broker halts message delivery for every dependent client. The Exploit Prediction Scoring System (EPSS) currently rates this vulnerability at a low near-term exploitation probability, but the low attack complexity and network reachability warrant prompt attention.

Root Cause

The root cause is improper resource release in the QoS (Quality of Service) database handling path invoked by nni_qos_db_set. Allocated structures associated with QoS state are not consistently freed under attacker-controlled input conditions on the TCP listener, resulting in unbounded memory growth. This aligns with a resource-exhaustion denial-of-service pattern rather than memory corruption or code execution.

Attack Vector

An attacker requires network reachability to the NanoMQ TCP listener, typically port 1883. No authentication is required if the broker is configured with default anonymous access. The attacker sends crafted MQTT packets that repeatedly invoke the vulnerable QoS state code path. Sustained traffic drives the broker process memory upward until the operating system terminates it or performance collapses.

No verified exploit code has been published beyond the researcher's proof-of-concept repository. Technical details are described in the NanoMQ Memory Leak Research README and the associated GitHub PoC repository.

Detection Methods for CVE-2026-36590

Indicators of Compromise

Progressive resident set size (RSS) growth of the nanomq broker process without corresponding client load increases
Broker restarts, OOM-killer events in dmesg, or systemd Main process exited entries referencing NanoMQ
Bursts of MQTT CONNECT, SUBSCRIBE, or PUBLISH packets carrying QoS 1 or QoS 2 flags from a limited set of source IPs

Detection Strategies

Correlate MQTT connection telemetry with broker process memory metrics to identify traffic patterns that precede memory spikes
Alert on abnormal ratios of QoS 1 or QoS 2 messages to overall MQTT throughput on exposed listeners
Ingest NanoMQ logs and host telemetry into a centralized analytics platform for cross-signal correlation between network events and process resource consumption

Monitoring Recommendations

Track memory utilization of the nanomq process with a rising-threshold alert tuned to baseline usage
Monitor MQTT listener connection counts and packet rates per source address
Log and review restarts of the broker service, treating unexpected restarts as investigation-worthy events

How to Mitigate CVE-2026-36590

Immediate Actions Required

Restrict network exposure of NanoMQ TCP listeners to trusted management networks or VPN segments
Enable authentication and access control lists on the broker to prevent anonymous clients from reaching the vulnerable code path
Apply memory and connection limits at the operating system or container level to contain resource exhaustion

Patch Information

No vendor patch has been referenced in the NVD entry at the time of publication. Track the EMQ NanoMQ project for releases after version 0.24.9 that address the nni_qos_db_set memory handling issue, and upgrade once a fixed release is available.

Workarounds

Place NanoMQ behind an MQTT-aware proxy or firewall that enforces per-client connection and message rate limits
Disable anonymous access and require client certificates or username/password authentication on the broker
Deploy the broker under a process supervisor with strict memory cgroup limits so that resource exhaustion triggers a controlled restart rather than a host-wide outage
Reduce or disable QoS 2 handling if the workload can tolerate at-most-once or at-least-once delivery semantics

bash

# Example systemd override to constrain nanomq memory
# /etc/systemd/system/nanomq.service.d/override.conf
[Service]
MemoryMax=512M
MemoryHigh=384M
Restart=on-failure
RestartSec=5s