What is the CVSS score of CVE-2026-36590?

CVE-2026-36590 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Which versions of NanoMQ are affected by CVE-2026-36590?

Organizations running EMQ NanoMQ 0.24.9 face operational disruption risk-the MQTT broker can be remotely crashed by unauthenticated attackers exhausting memory resources through a…

How to fix or mitigate CVE-2026-36590?

Within 24 hours, inventory all EMQ NanoMQ 0.24.9 instances and restrict MQTT broker network access to authorized clients only via firewall rules or network segmentation to block untrusted traffic. Within 7 days, contact the vendor for patch timelines and implement resource limits (memory and CPU cgroups or Kubernetes quotas) to contain crash impact; enable monitoring for abnormal connection spikes and memory growth patterns. Within 30 days, upgrade to a patched NanoMQ version when released by the vendor, establish automated patch-tracking for NanoMQ security updates, and implement broker redundancy or failover clustering to mitigate single-point availability failure.

NanoMQ CVE-2026-36590

EUVD-2026-44847 HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-07-15 mitre

GHSA-2gm5-wc63-c2pc

Denial Of Service N A

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

Network-reachable broker, unauthenticated MQTT traffic with low complexity (AV:N/AC:L/PR:N/UI:N); memory-leak resource exhaustion yields availability-only impact (A:H, C:N/I:N).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 16, 2026 - 19:24 vuln.today

CVSS changed

Jul 16, 2026 - 19:22 NVD

7.5 (HIGH)

CVE Published

Jul 15, 2026 - 00:00 cve.org

HIGH 7.5

CVE Published

Jul 15, 2026 - 00:00 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

An issue in EMQ NanoMQ v.0.24.9 allows a remote attacker to cause a denial of service via the nni_qos_db_set function in broker_tcp.c component

AnalysisAI

Remote denial of service in EMQ NanoMQ 0.24.9 lets an unauthenticated network attacker exhaust broker resources through the nni_qos_db_set function in the broker_tcp.c TCP-handling component, degrading or crashing the MQTT broker (CVSS 7.5, availability-only). Publicly available exploit/research code exists in a memory-leak research repository, but there is no public evidence of active exploitation and EPSS estimates a low 0.29% (21st percentile) exploitation probability. The flaw is a CWE-400 uncontrolled-resource-consumption / memory-leak issue rather than a code-execution or data-disclosure bug.

Technical ContextAI

NanoMQ is EMQ's ultra-lightweight, high-performance MQTT message broker written in C and designed for IoT edge and embedded messaging workloads, built on the NNG (nanomsg-next-generation) networking library. The defect lives in broker_tcp.c, the module that handles incoming TCP MQTT client connections, specifically in nni_qos_db_set, which manages the QoS (Quality of Service) message-state database used for MQTT QoS 1/2 delivery tracking. The classified root cause is CWE-400 (Uncontrolled Resource Consumption); the referenced research characterizes it as a memory leak, meaning attacker-driven MQTT traffic causes the broker to allocate memory (QoS state) that is never reclaimed, steadily consuming RAM until the process degrades or is killed.

RemediationAI

No vendor-released patch identified at time of analysis; no fixed NanoMQ version is cited in the input, so monitor the NanoMQ GitHub project and EMQ advisories and upgrade to a released version that specifically addresses the broker_tcp.c / nni_qos_db_set resource leak once published. In the interim, apply compensating controls: restrict TCP access to the NanoMQ MQTT listener (default 1883, and any TLS 8883) to trusted client subnets via firewall or security-group rules so untrusted hosts cannot open connections, which trades off reachability for legitimate remote IoT devices; enforce MQTT authentication/ACLs and TLS client certificates to reduce the anonymous attack surface, at the cost of provisioning credentials to fleet devices; place the broker behind a reverse proxy or connection rate-limiter to cap connection/message rates that drive QoS-state allocation; and add memory-usage monitoring with automatic restart (systemd/container OOM policy) as a stopgap to recover availability, accepting that restarts drop in-flight sessions. Consult the VulDB advisory (https://vuldb.com/vuln/379466) and the research README (https://github.com/MoXie25/NanoMQ-Memory-Leak-Research/blob/main/README.md) for reproduction details to validate mitigations.