CVE-2024-48077: NanoMQ Denial of Service Vulnerability

CVE-2024-48077 Overview

A Denial of Service (DoS) vulnerability exists in NanoMQ v0.22.7, an ultra-lightweight and high-performance MQTT broker for IoT Edge. The vulnerability allows attackers to send crafted requests that cause the recv-q queue of the NanoMQ process to continuously accumulate data packets, ultimately triggering a deadlock condition that renders the broker unable to provide normal services.

Critical Impact

Attackers can remotely disrupt MQTT broker services by exploiting this resource exhaustion vulnerability, potentially affecting all connected IoT devices and applications relying on the message broker.

Affected Products

• NanoMQ v0.22.7
• Other versions may also be affected (verify with vendor)

Discovery Timeline

• 2026-01-15 - CVE CVE-2024-48077 published to NVD
• 2026-01-16 - Last updated in NVD database

Technical Details for CVE-2024-48077

Vulnerability Analysis

This vulnerability falls under CWE-400 (Uncontrolled Resource Consumption), a class of weaknesses where an application does not properly restrict the amount of resources that can be consumed. In the case of NanoMQ, the MQTT broker fails to adequately manage incoming data packets in the receive queue (recv-q), allowing an attacker to overwhelm the system with specially crafted requests.

The attack exploits the broker's inability to enforce proper rate limiting or queue depth management. As malicious packets accumulate in the receive queue without being properly processed or discarded, the system enters a deadlock state where critical processing threads become blocked, preventing the broker from servicing legitimate MQTT publish/subscribe operations.

Root Cause

The root cause stems from improper resource consumption controls in NanoMQ's network packet handling mechanism. The broker does not implement adequate safeguards to limit the growth of the recv-q queue or to detect and respond to queue exhaustion scenarios. This allows an attacker to flood the queue with crafted packets that are not properly processed, leading to resource exhaustion and eventual deadlock.

Attack Vector

The vulnerability is exploitable over the network without requiring authentication or user interaction. An attacker can send specially crafted MQTT or network packets to the NanoMQ broker's listening port. The packets are designed to be queued but not properly processed, causing the receive queue to grow unboundedly.

As the queue fills with unprocessed packets, the broker's internal synchronization mechanisms become overwhelmed, leading to thread contention and eventually a complete deadlock. Once in this state, the broker cannot recover without manual intervention and restart.

Technical details and proof-of-concept information are available in the GitHub Gist PoC published by the security researcher.

Detection Methods for CVE-2024-48077

Indicators of Compromise

• Abnormally high recv-q values in NanoMQ process network statistics (visible via ss or netstat commands)
• NanoMQ broker becoming unresponsive to legitimate MQTT client connections
• Increasing memory consumption by the NanoMQ process without corresponding increase in legitimate client activity
• Connection timeouts reported by MQTT clients attempting to connect to the broker

Detection Strategies

• Monitor NanoMQ process recv-q queue depth using system monitoring tools and alert on thresholds exceeding normal baseline values
• Implement connection rate monitoring to detect unusual patterns of incoming connections or packet floods
• Deploy network intrusion detection systems (NIDS) with rules to identify MQTT protocol anomalies
• Use application performance monitoring (APM) to track broker responsiveness and detect service degradation

Monitoring Recommendations

• Establish baseline metrics for normal recv-q queue depth and set alerting thresholds at 2-3x normal levels
• Configure automated health checks that verify MQTT broker responsiveness through test publish/subscribe operations
• Monitor system resources (CPU, memory, file descriptors) for the NanoMQ process to detect resource exhaustion patterns
• Implement centralized logging to capture connection attempts and identify potential attack sources

How to Mitigate CVE-2024-48077

Immediate Actions Required

• Upgrade NanoMQ to a patched version if available from the vendor
• Implement network-level rate limiting to restrict the number of connections and packets per source IP
• Deploy a reverse proxy or load balancer with DoS protection capabilities in front of the MQTT broker
• Restrict network access to the NanoMQ broker to trusted IP ranges using firewall rules

Patch Information

Check the NanoMQ GitHub Repository for the latest releases and security patches addressing this vulnerability. Monitor the project's security advisories and release notes for updates specifically addressing CVE-2024-48077.

Workarounds

• Configure operating system-level socket buffer limits to constrain queue growth using sysctl parameters
• Implement firewall rules to rate-limit incoming connections to the MQTT broker port
• Deploy NanoMQ behind a network appliance or proxy capable of traffic shaping and anomaly detection
• Consider running multiple NanoMQ instances behind a load balancer to distribute load and isolate failures

# Configuration example - Network rate limiting with iptables
# Limit new MQTT connections to 100 per minute per source IP
iptables -A INPUT -p tcp --dport 1883 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 1883 -m state --state NEW -m recent --update --seconds 60 --hitcount 100 -j DROP

# Limit overall packet rate to MQTT port
iptables -A INPUT -p tcp --dport 1883 -m limit --limit 1000/second --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP