Nanomq CVE-2024-42646

This vulnerability presents HIGH real-world risk despite no KEV or EPSS data being provided: (1) CVSS 7.5 with AV:N/AC:L/PR:N indicates trivial exploitability—any network attacker can trigger the crash without privilege escalation or complex attack chains; (2) The availability impact is complete (A:H), resulting in service downtime; (3) No authentication required (PR:N) means compromised IoT devices, lateral network movement, or public Internet exposure all enable exploitation; (4) CWE-125 (Out-of-bounds Read) is a stable, well-understood vulnerability class with reliable exploit patterns; (5) Message brokers are critical infrastructure in industrial IoT, smart home, and healthcare deployments—downtime has cascading effects. Without KEV status or POC availability data, assume proof-of-concept is feasible given the straightforward MQTT protocol and public message format specifications. SSVC considerations: Exploitation is likely 'Active' or 'Proof-of-Concept', technical impact is 'Complete' (service unavailable), and automatable attacks are probable. Priority should be HIGH for any production NanoMQ deployment.

An attacker on the same network or Internet (if broker is exposed) connects to the NanoMQ MQTT broker on port 1883 and sends a specially crafted MQTT CONNECT, PUBLISH, or SUBSCRIBE message with malformed variable-length fields (e.g., oversized topic name, invalid remaining length encoding, or corrupted UTF-8 strings). The broker's message parser attempts to read beyond allocated buffer boundaries during deserialization, triggering a segmentation fault and crashing the process. The broker becomes unavailable, disrupting all connected IoT devices, sensor networks, or dependent applications. If no automated recovery is in place, administrators must manually restart the service. In industrial settings, this could halt production lines, interrupt remote patient monitoring, or disable smart building controls. No authentication is required—an unauthenticated attacker from any network segment can trigger the crash. Proof-of-concept would involve fuzzing MQTT message fields or reverse-engineering the parser from the NanoMQ source code (available on GitHub).