CVE-2024-48077: NanoMQ Broker DoS via Uncontrolled Receive Queue Exhaustion

CVE ID: CVE-2024-48077
Product: NanoMQ MQTT Broker
Affected version: NanoMQ v0.22.7
Vulnerability type: Denial of Service (Resource Exhaustion / Deadlock)
CVSS v3.1 score: 7.5 – High
Attack vector: Network
Privileges required: None
User interaction: None
Impact: Service crash, deadlock, or complete broker unavailability
Exploit availability: Public technical write-ups and educational PoC concepts exist (traffic-flood based)
Exploit maturity: Low-to-moderate (easy to reproduce in lab environments)

Executive summary

This vulnerability allows a remote attacker to knock a NanoMQ broker offline by overwhelming it with MQTT traffic. The broker does not properly control how much data it queues while receiving packets. As traffic piles up, NanoMQ consumes system resources until it stalls or crashes, making MQTT services unavailable to all legitimate clients.

This is a pure availability attack. No data is stolen or modified, but production systems can be rendered unusable.

Technical explanation

NanoMQ internally maintains a receive queue (recv-q) for incoming network packets. In version 0.22.7, this queue is not sufficiently protected against abuse.

An attacker can:

Open many TCP connections to the MQTT port (1883 / 8883 / WebSocket)
Or send a very high rate of MQTT packets (valid or malformed)
Or do both at the same time

As packets arrive faster than NanoMQ can process them:

The recv-q grows uncontrollably
File descriptors and async I/O workers are exhausted
Threads block waiting for resources
Eventually the broker enters a deadlock or stops responding

At this point, all MQTT clients lose connectivity until the process is restarted.

This maps to:

Uncontrolled Resource Consumption
Deadlock due to queue starvation

How an attacker would exploit this

Attacker scans the internet for exposed MQTT brokers.
Finds a NanoMQ instance running v0.22.7.
Starts sending:
- Thousands of MQTT CONNECT / PUBLISH packets per second, or
- Many short-lived TCP connections, or
- A mix of malformed and oversized MQTT frames.
NanoMQ accepts the traffic and queues it.
The receive queue grows faster than it can drain.
System resources are exhausted.
Broker becomes unresponsive or crashes.

No authentication is required.
No valid MQTT credentials are required.

Proof-of-Concept (PoC) availability (educational use only)

Publicly available technical notes describe how packet flooding causes recv-q exhaustion.
The attack does not require special exploit code — basic traffic generators, MQTT clients, or custom scripts can reproduce the issue.
This makes the vulnerability easy to test in a lab and dangerous if exposed to the internet.

Indicators of exploitation

On the NanoMQ host

Broker becomes slow or unresponsive
Sudden spike in open file descriptors
High CPU usage without corresponding throughput
Broker stops accepting new MQTT connections
Process appears “alive” but does no useful work (deadlock)

In system/network tools

Recv-Q values growing rapidly in ss or netstat
Thousands of connections or packets from a single IP or small IP range
Large number of sockets in ESTABLISHED or CLOSE_WAIT state

Log sources to monitor

Source	Why it matters
NanoMQ broker logs	May show queue pressure, async I/O errors, or socket warnings
System logs (`journalctl`, `syslog`)	File descriptor exhaustion, kernel socket warnings
Network flow logs	Abnormally high traffic to MQTT ports
IDS / NDR	Repeated MQTT packet bursts
Host metrics	FD count, memory growth, thread exhaustion

Detection ideas & rules

Zeek detection rules (example)

1. Detect excessive MQTT connections from one host

event zeek_init()
{
  Log::create_stream(MQTT_Flood::LOG, [$columns=MQTT_Flood::Info]);
}

module MQTT_Flood;

export {
  redef enum Log::ID += { LOG };

  type Info: record {
    ts: time &log;
    src: addr &log;
    conn_count: count &log;
  };
}

global mqtt_conn_counter: table[addr] of count &default=0;

event new_connection(c: connection)
{
  if ( c$id$resp_p == 1883 || c$id$resp_p == 8883 )
  {
    mqtt_conn_counter[c$id$orig_h] += 1;

    if ( mqtt_conn_counter[c$id$orig_h] > 200 )
    {
      Log::write(MQTT_Flood::LOG, [
        $ts = network_time(),
        $src = c$id$orig_h,
        $conn_count = mqtt_conn_counter[c$id$orig_h]
      ]);
    }
  }
}

Clients that rapidly open excessive MQTT connections — a strong DoS indicator.

2. Detect high-rate MQTT traffic (packet flood heuristic)

event connection_established(c: connection)
{
  if ( c$id$resp_p == 1883 || c$id$resp_p == 8883 )
  {
    if ( c$orig$num_pkts > 5000 )
    {
      NOTICE([$note=Notice::Policy,
              $msg="Possible MQTT packet flood detected",
              $conn=c]);
    }
  }
}

Payload characteristics

Repeated MQTT CONNECT frames without session teardown
High-rate PUBLISH packets with minimal payload
TCP sessions with small packets sent continuously
Many incomplete MQTT handshakes

This is volume-based, not protocol-logic exploitation.

Safe troubleshooting & forensic snapshot script

Purpose:
Collect quick evidence from a host without modifying anything.

#!/bin/bash
# NanoMQ DoS forensic snapshot (read-only)

TS=$(date +"%Y%m%d_%H%M%S")
OUT="/tmp/nanomq_snapshot_$TS"
PID=$(pidof nanomq)

mkdir -p "$OUT"

echo "[+] Collecting socket stats..."
ss -tanp > "$OUT/ss_tanp.txt"
netstat -anp > "$OUT/netstat_anp.txt"

echo "[+] Collecting file descriptor usage..."
if [ -n "$PID" ]; then
  ls -l /proc/$PID/fd > "$OUT/nanomq_fds.txt"
  cat /proc/$PID/limits > "$OUT/nanomq_limits.txt"
fi

echo "[+] Collecting lsof output..."
lsof -p "$PID" > "$OUT/lsof_nanomq.txt" 2>/dev/null

echo "[+] Collecting NanoMQ logs..."
cp -r /var/log/nanomq* "$OUT/" 2>/dev/null

echo "[+] Collecting system load..."
uptime > "$OUT/uptime.txt"
free -m > "$OUT/memory.txt"
df -h > "$OUT/disk.txt"

echo "[+] Snapshot completed: $OUT"

Why this is safe

Read-only commands only
No configuration changes
No service restarts
Suitable for incident response evidence

Mitigation strategies

Immediate

Restrict access to MQTT ports (allowlist trusted clients)
Apply connection and rate limits at firewall or load balancer
Block abusive IPs identified via logs or Zeek alerts

Short-term hardening

Run NanoMQ behind a TCP proxy with rate limiting
Monitor Recv-Q, FD counts, and memory usage
Alert on abnormal MQTT traffic patterns

Permanent fix

Upgrade NanoMQ to a vendor-patched release as soon as it is available.

Official patch / upgrade link

https://github.com/nanomq/nanomq/releases

Always use the latest stable release that explicitly lists fixes for CVE-2024-48077 in the changelog.

MITRE mapping

CWE-400: Uncontrolled Resource Consumption
CWE-833: Deadlock
MITRE ATT&CK: T1499 – Endpoint Denial of Service

Final takeaway

If your NanoMQ broker is:

Internet-facing
Running v0.22.7
Not protected by rate limits

Then exploitation is realistic and low-effort.

This vulnerability should be treated as high priority, especially in IoT or production MQTT environments.