CVE-2026-34608: NanoMQ MQTT Broker Buffer Overflow Flaw

CVE-2026-34608 Overview

CVE-2026-34608 is an Out-of-Bounds Read vulnerability affecting NanoMQ MQTT Broker, an all-around Edge Messaging Platform designed for IoT and edge computing environments. The vulnerability exists in the hook_work_cb() function within the webhook_inproc.c file, where improper handling of message body buffers can lead to memory access beyond allocated boundaries.

The flaw occurs when the function processes nng messages by parsing the message body with cJSON_Parse(body). The body is obtained from nng_msg_body(msg), which returns a binary buffer without a guaranteed null terminator. Since cJSON_Parse reads until it encounters a \0 character, it can potentially access memory beyond the allocated buffer, including nng_msg metadata or adjacent heap/stack memory.

Critical Impact

Remote attackers with high privileges can exploit this vulnerability to cause denial of service conditions by crafting specially formatted JSON payloads with specific size characteristics.

Affected Products

• NanoMQ MQTT Broker versions prior to 0.24.10
• Edge messaging deployments using vulnerable NanoMQ webhook functionality
• IoT infrastructure utilizing NanoMQ's inproc webhook processing

Discovery Timeline

• April 2, 2026 - CVE-2026-34608 published to NVD
• April 2, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34608

Vulnerability Analysis

This Out-of-Bounds Read vulnerability stems from a fundamental mismatch between how nng message bodies are structured and how the cJSON parsing library expects input data. The nng_msg_body(msg) function returns a pointer to a binary buffer that does not include a null terminator, while cJSON_Parse() expects a null-terminated C string.

The vulnerability is particularly interesting because it is often masked by nng's internal allocation padding behavior. When nng allocates memory for messages with non-power-of-two sizes less than 1024 bytes or non-aligned sizes, it adds extra 32 bytes of zeros as padding. This padding inadvertently provides the null termination that cJSON_Parse expects.

However, the out-of-bounds read is reliably triggered when the JSON payload length is a power-of-two equal to or greater than 1024 bytes. In these cases, no padding is added to the allocation, and cJSON_Parse will read past the end of the message buffer searching for the terminating null character.

Root Cause

The root cause is the failure to properly determine the message body length before passing it to JSON parsing functions. The code directly passed the raw message body pointer to cJSON_Parse() without ensuring proper null termination or using a length-aware parsing approach. This represents a classic case of improper input validation (CWE-125) where the boundary of the data buffer is not respected.

Attack Vector

The vulnerability can be exploited remotely over the network by authenticated attackers with high privileges. An attacker would need to:

1. Establish a connection to the NanoMQ broker with appropriate credentials
2. Craft a JSON message payload with a length that is a power-of-two (e.g., 1024, 2048, 4096 bytes)
3. Send the malicious message through the webhook functionality
4. The hook_work_cb() function processes the message and triggers the out-of-bounds read

The attack does not require user interaction and can result in denial of service through application crash or unexpected behavior when accessing invalid memory regions.

 	struct hook_work *work = arg;
 	int               rv;
 	char *            body;
+	size_t            body_len;
 	conf_exchange *   exconf = work->exchange;
 	conf_parquet *    parquetconf = work->parquet;
 	nng_msg *         msg;

Source: GitHub Commit Details

The patch introduces a body_len variable to track the message body length before JSON parsing, enabling proper bounds checking.

Detection Methods for CVE-2026-34608

Indicators of Compromise

• Unexpected NanoMQ broker crashes or restarts, particularly when processing webhook messages
• Memory access violations or segmentation faults in NanoMQ process logs
• Anomalous JSON payloads with sizes that are exact powers of two (1024, 2048, 4096 bytes, etc.)
• Increased memory read errors in system monitoring for NanoMQ processes

Detection Strategies

• Monitor NanoMQ application logs for segmentation faults or memory access errors in the webhook_inproc module
• Implement network traffic analysis to detect unusually sized MQTT messages targeting webhook endpoints
• Deploy memory sanitizers (AddressSanitizer) in development/staging environments to detect out-of-bounds reads
• Use application-level monitoring to track crashes originating from the hook_work_cb() function

Monitoring Recommendations

• Enable verbose logging for NanoMQ webhook processing to capture message size information
• Implement alerting for NanoMQ process crashes or unexpected restarts
• Monitor system logs for SIGSEGV signals associated with the NanoMQ process
• Track message throughput anomalies that may indicate exploitation attempts

How to Mitigate CVE-2026-34608

Immediate Actions Required

• Upgrade NanoMQ to version 0.24.10 or later immediately
• Review webhook configurations and temporarily disable non-essential webhook integrations until patching is complete
• Restrict network access to NanoMQ broker endpoints to trusted sources only
• Implement additional input validation at network perimeter for MQTT traffic

Patch Information

The vulnerability has been patched in NanoMQ version 0.24.10. The fix modifies the hook_work_cb() function in webhook_inproc.c to properly retrieve and validate the message body length before JSON parsing. Organizations should upgrade to this version or later to remediate the vulnerability.

For detailed patch information, refer to:

• GitHub Security Advisory GHSA-8p57-jxj9-3qq3
• GitHub Release Version 0.24.10

Workarounds

• Restrict webhook functionality to trusted internal networks only until the patch can be applied
• Implement network-level filtering to limit maximum message sizes to non-power-of-two values
• Deploy a reverse proxy with request body size validation in front of NanoMQ endpoints
• Consider temporarily disabling webhook functionality if not critical to operations

# Example: Restrict NanoMQ network access using iptables
# Allow only trusted networks to access NanoMQ (adjust IP ranges as needed)
iptables -A INPUT -p tcp --dport 8883 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8883 -j DROP

# Monitor NanoMQ process for crashes
journalctl -u nanomq -f | grep -i "segfault\|crash\|error"