CVE-2026-25627: Emqx Nanomq MQTT Broker DoS Vulnerability

CVE-2026-25627 Overview

NanoMQ MQTT Broker is an all-around Edge Messaging Platform that provides lightweight MQTT message broker capabilities for IoT and edge computing environments. A critical out-of-bounds read vulnerability has been discovered in NanoMQ's MQTT-over-WebSocket transport prior to version 0.24.8. The vulnerability can be triggered remotely by sending a maliciously crafted MQTT packet with a deliberately large Remaining Length value in the fixed header while providing a significantly shorter actual payload. This causes the code path to copy more bytes than available in the receive buffer, resulting in an out-of-bounds read that crashes the broker service.

Critical Impact

Remote attackers can crash NanoMQ MQTT broker instances by exploiting the WebSocket listener, causing denial of service for all connected IoT devices and edge applications relying on the messaging platform.

Affected Products

• emqx nanomq versions prior to 0.24.8
• NanoMQ MQTT-over-WebSocket transport component
• Edge deployments using NanoMQ WebSocket listeners

Discovery Timeline

• 2026-03-30 - CVE CVE-2026-25627 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-25627

Vulnerability Analysis

This vulnerability is classified as CWE-125 (Out-of-Bounds Read). The flaw exists in how NanoMQ's MQTT-over-WebSocket transport handles the Remaining Length field in MQTT fixed headers. When processing incoming WebSocket messages, the code trusts the Remaining Length value specified in the MQTT packet header without validating that the actual payload buffer contains sufficient data. This allows an attacker to specify an arbitrarily large Remaining Length while sending a much smaller payload, causing the broker to read beyond the bounds of the allocated receive buffer.

The vulnerability is remotely exploitable over the network without requiring authentication or user interaction. An attacker can target any exposed NanoMQ WebSocket listener to trigger the condition. Address Sanitizer (ASAN) testing confirms the out-of-bounds read condition leads to an immediate crash, making this a reliable denial-of-service vector against affected NanoMQ deployments.

Root Cause

The root cause is insufficient input validation in the MQTT packet parsing logic within the WebSocket transport layer. Specifically, the code copies data based on the Remaining Length field value without first verifying that the current receive buffer actually contains that many bytes. This missing boundary check allows the read operation to exceed buffer limits when processing malformed packets.

Attack Vector

The attack vector is network-based, targeting NanoMQ's WebSocket listener (typically running on the default MQTT-over-WebSocket port). An attacker establishes a WebSocket connection to the broker and sends a specially crafted MQTT packet. The malicious packet contains a fixed header with an inflated Remaining Length value that exceeds the actual payload size. When the broker attempts to process this packet, the buffer read operation exceeds boundaries, causing an immediate crash. No authentication is required, and the attack can be executed with a single malicious packet.

// Security patch from NanoNNG - reordering operations to prevent UAF/OOB issues
// Source: https://github.com/nanomq/NanoNNG/commit/e80b30bad6d855593a68d18f2785bfaca6faf09e

 
 	nni_lmq_fini(&p->rslmq);
 	nni_mtx_fini(&p->mtx);
-	NNI_FREE_STRUCT(p);
 	log_trace(" ************ tlstran_pipe_finit [%p] ************ ", p);
+	NNI_FREE_STRUCT(p);
 }
 
 static void

Source: GitHub Commit e80b30b

Detection Methods for CVE-2026-25627

Indicators of Compromise

• Unexpected NanoMQ broker crashes or service restarts correlating with WebSocket connection attempts
• Core dumps or crash logs showing out-of-bounds read errors in MQTT packet processing functions
• Network traffic containing MQTT packets with abnormally large Remaining Length values relative to payload size
• WebSocket connections from external sources that terminate immediately after sending minimal data

Detection Strategies

• Deploy network intrusion detection rules to identify MQTT packets where the declared Remaining Length exceeds the actual packet size
• Monitor NanoMQ process stability and configure alerts for unexpected terminations or restart patterns
• Implement WebSocket traffic analysis to detect malformed MQTT handshake attempts
• Enable ASAN or similar memory debugging in development/staging environments to catch boundary violations

Monitoring Recommendations

• Configure centralized logging for NanoMQ broker instances to capture crash events and stack traces
• Set up availability monitoring with automatic alerting when WebSocket listeners become unresponsive
• Track connection patterns to identify potential DoS attack sources targeting WebSocket endpoints
• Review NanoMQ access logs for repeated connection attempts from suspicious IP addresses

How to Mitigate CVE-2026-25627

Immediate Actions Required

• Upgrade NanoMQ to version 0.24.8 or later immediately on all affected deployments
• If immediate patching is not possible, disable or restrict access to WebSocket listeners pending upgrade
• Implement network-level access controls to limit WebSocket listener exposure to trusted sources only
• Monitor affected systems for signs of exploitation attempts until patching is complete

Patch Information

EMQ has released version 0.24.8 which addresses this vulnerability. The fix is available through the official NanoMQ releases. The patch adds proper validation of the Remaining Length field against the actual received buffer size before performing copy operations. For detailed technical information about the fix, refer to the GitHub Pull Request #1405 and the GitHub Security Advisory GHSA-w4rh-v3h2-j29x.

Workarounds

• Disable MQTT-over-WebSocket transport if not required and use standard MQTT TCP transport instead
• Place NanoMQ WebSocket listeners behind a reverse proxy or load balancer with request validation capabilities
• Implement firewall rules to restrict WebSocket listener access to known trusted IP ranges
• Deploy rate limiting on WebSocket connections to slow potential DoS exploitation attempts

# Configuration example - Restrict WebSocket listener access via firewall
# Block external access to NanoMQ WebSocket port (example: 8083)
iptables -A INPUT -p tcp --dport 8083 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8083 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 8083 -j DROP