CVE-2026-36590: 
NixOS vulnerability analysis and mitigation

CVE-2026-36590 is a denial-of-service vulnerability in EMQ NanoMQ v0.24.9 caused by a memory leak in the nni_qos_db_set function within the broker_tcp.c component. A remote, unauthenticated attacker can exploit this flaw by sending repeated MQTT QoS > 0 PUBLISH messages, gradually exhausting system memory and crashing the broker. The vulnerability was publicly disclosed on June 17, 2026, and registered in NVD on July 15, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, PoC Research).

The root cause is classified as CWE-772 (Missing Release of Resource after Effective Lifetime) and CWE-400 (Uncontrolled Resource Consumption). The vulnerability is triggered when NanoMQ is built without SQLite support (NNG_SUPP_SQLITE undefined) but the runtime configuration has sqlite.enable = true, leaving the QoS database pointer (db) as NULL. When a QoS > 0 MQTT PUBLISH message is processed, nni_qos_db_set() in mqtt_qos_db_api.c performs an early return upon detecting the NULL db pointer without calling nni_msg_free(msg), orphaning the cloned message reference (reference count remains at 1 instead of being decremented to 0). ASAN analysis confirmed that leaked bytes and allocations scale linearly with the number of trigger attempts, demonstrating input-count-dependent memory exhaustion (PoC Research, Github Advisory).

Successful exploitation causes a silent, progressive denial of service: the NanoMQ MQTT broker gradually exhausts available system memory (OOM condition) and eventually crashes, disrupting all connected MQTT clients and IoT devices relying on the broker. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Because NanoMQ is commonly deployed in IoT and industrial environments, broker unavailability can have downstream operational consequences for connected devices (PoC Research, Github Advisory).

1. Identify target: Locate internet-facing or network-accessible NanoMQ v0.24.9 broker instances (default MQTT port 1883 or 8883 for TLS) using network scanning tools such as Shodan or nmap.
2. Verify misconfiguration precondition: Confirm the target broker is running with sqlite.enable = true in nanomq.conf but was compiled without SQLite support — this can be inferred from broker behavior or version/build metadata if exposed.
3. Prepare PoC script: Obtain or adapt the public Python PoC (249exploit_leak.py) from the research repository, which uses an MQTT client library to connect to the target broker.
4. Send crafted MQTT messages: Execute the PoC script to repeatedly publish MQTT messages with QoS level 1 or 2 to the broker. Each message triggers the nni_qos_db_set early-return path, leaking one message reference worth of memory per iteration.
5. Sustain the attack: Continue sending QoS > 0 PUBLISH messages in volume (e.g., 500+ rounds as demonstrated in ASAN tests). Memory consumption grows proportionally with message count.
6. Achieve DoS: The broker process exhausts available system memory, triggering an OOM condition and crashing the NanoMQ service, denying service to all legitimate MQTT clients (PoC Research).

• Network: Sustained high-volume MQTT PUBLISH traffic with QoS level 1 or 2 from a single or small set of source IPs; unusual connection patterns to port 1883/8883 with repeated publish bursts.
• Process/System: Steadily increasing memory consumption by the nanomq process over time without corresponding release; OOM killer events in system logs (dmesg or /var/log/syslog) referencing the NanoMQ process.
• Logs: NanoMQ runtime logs showing no SQLite initialization messages despite sqlite.enable = true in configuration; absence of expected QoS persistence log entries.
• File System: Presence of nanomq.conf with sqlite.enable = true on a build that lacks SQLite support (verifiable by checking build flags or absence of SQLite libraries linked to the binary) (PoC Research).

No official vendor patch version has been specified at this time; the NanoMQ team has disputed the issue as configuration-related. As immediate workarounds: (1) set sqlite.enable = false in nanomq.conf if the binary was not compiled with SQLite support; (2) restrict MQTT broker access to trusted clients only using network-level access controls (firewall rules, VPN, or authentication); (3) rebuild NanoMQ with explicit SQLite support (-DNNG_SUPP_SQLITE) if persistence is required. The researcher recommends the vendor add startup validation to detect the SQLite configuration mismatch and add nni_msg_free(msg) in the db == NULL early-return branch of nni_qos_db_set (PoC Research, Github Advisory).

The NanoMQ vendor team has disputed the vulnerability, characterizing it as a configuration-related issue rather than a software defect. The researcher (MoXie25) published a detailed technical rebuttal arguing that the broker's silent acceptance of an invalid configuration — rather than failing at startup — constitutes a security-relevant flaw, and that the resulting memory leak is remotely triggerable. The GitHub Advisory Database lists the advisory as "Unreviewed," and the CVE's final classification remains pending determination by the CVE Team or relevant CNA (PoC Research, Github Advisory).