CVE-2026-32696: NanoMQ MQTT Broker DoS Vulnerability

CVE-2026-32696 Overview

CVE-2026-32696 is a Null Pointer Dereference vulnerability affecting NanoMQ MQTT Broker, an all-around Edge Messaging Platform. The vulnerability exists in NanoMQ version 0.24.6 when HTTP authentication (auth.http_auth) is enabled. When a client connects to the broker using MQTT CONNECT without providing username/password credentials, and the configuration uses placeholder parameters %u or %P for username and password respectively, the HTTP request construction phase enters auth_http.c:set_data(). This results in calling strlen() on a NULL pointer, causing a SIGSEGV crash that can be triggered remotely, resulting in a denial of service condition.

Critical Impact

Remote attackers can crash the NanoMQ MQTT broker by sending MQTT CONNECT packets without credentials when HTTP authentication is configured with placeholder parameters, causing service disruption for all connected IoT devices and edge messaging clients.

Affected Products

• NanoMQ MQTT Broker version 0.24.6
• NanoMQ deployments with auth.http_auth enabled
• Configurations using %u or %P placeholders for HTTP authentication

Discovery Timeline

• 2026-03-30 - CVE-2026-32696 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-32696

Vulnerability Analysis

This vulnerability is classified as CWE-476 (NULL Pointer Dereference). The flaw resides in the HTTP authentication handling code within the auth_http.c source file. When NanoMQ is configured to use HTTP-based authentication with placeholder variables for username (%u) and password (%P), the broker expects these values to be populated from incoming MQTT CONNECT packets.

The vulnerable code path is triggered when a client initiates an MQTT connection without supplying authentication credentials. In this scenario, the username and password fields remain NULL. When the set_data() function attempts to construct the HTTP authentication request, it calls strlen() on these NULL pointers without first validating that they contain valid data. This results in a segmentation fault (SIGSEGV) that immediately terminates the broker process.

The vulnerability requires network access and specific configuration conditions—namely that HTTP authentication must be enabled with placeholder parameters. While the attack complexity is higher due to these prerequisites, the impact is significant for affected deployments as it allows unauthenticated remote attackers to crash the messaging broker.

Root Cause

The root cause is improper input validation in the set_data() function within auth_http.c. The function fails to check whether the username and password pointers are NULL before passing them to strlen(). When these values are absent from an MQTT CONNECT packet, the NULL pointers are dereferenced, causing the application to crash. The fix implemented in version 0.24.7 adds proper NULL checks before string operations are performed on authentication credentials.

Attack Vector

The attack vector is network-based. An attacker can exploit this vulnerability by:

1. Identifying a NanoMQ broker instance with HTTP authentication enabled using placeholder configuration
2. Establishing a TCP connection to the MQTT broker port (typically 1883 or 8883)
3. Sending a malformed MQTT CONNECT packet that omits username and password fields
4. The broker's HTTP authentication handler attempts to process the empty credentials
5. The strlen() call on NULL pointer causes SIGSEGV, crashing the broker service

The vulnerability manifests in the auth_http.c:set_data() function during HTTP request construction. When placeholder parameters %u (username) and %P (password) are configured, the code expects these values to be substituted with actual credentials from the MQTT CONNECT packet. Without proper NULL validation, absent credentials trigger the crash. See the GitHub Security Advisory GHSA-77f4-wvq8-mp3p for additional technical details.

Detection Methods for CVE-2026-32696

Indicators of Compromise

• Unexpected NanoMQ broker process terminations with SIGSEGV signals in system logs
• Core dump files indicating crashes in auth_http.c or related authentication functions
• Multiple MQTT connection attempts from suspicious sources without credentials
• Service availability interruptions correlating with incoming MQTT traffic

Detection Strategies

• Monitor system logs for NanoMQ segmentation fault (signal 11) events
• Implement network intrusion detection rules to flag MQTT CONNECT packets without authentication fields targeting systems with HTTP auth enabled
• Configure process monitoring to alert on unexpected NanoMQ daemon restarts
• Review MQTT broker access logs for connection attempts lacking username/password fields

Monitoring Recommendations

• Enable verbose logging for NanoMQ authentication subsystem to capture failed auth attempts
• Deploy watchdog services to automatically restart crashed broker instances and alert administrators
• Implement network-level monitoring for anomalous MQTT traffic patterns
• Configure centralized log aggregation to correlate crash events with connection attempts

How to Mitigate CVE-2026-32696

Immediate Actions Required

• Upgrade NanoMQ to version 0.24.7 or later immediately
• If immediate upgrade is not possible, consider temporarily disabling HTTP authentication or enforcing credentials at the network level
• Review NanoMQ configuration to identify use of %u and %P placeholders
• Implement network access controls to limit MQTT broker exposure to trusted clients only

Patch Information

The vulnerability has been patched in NanoMQ version 0.24.7. The fix is available through the GitHub Release v0.24.7. The patch adds proper NULL pointer validation before string operations are performed on authentication credentials. Technical details of the fix can be reviewed in GitHub Pull Request #1394 and the GitHub Commit Update.

Workarounds

• Temporarily disable HTTP authentication (auth.http_auth) if the feature is not critical to operations
• Place NanoMQ behind a reverse proxy or firewall that validates MQTT credentials before forwarding
• Configure network ACLs to restrict broker access to authenticated network segments only
• Use alternative authentication mechanisms that do not rely on placeholder parameter substitution

# Configuration example - Restrict MQTT broker access via firewall
# Allow only trusted networks to access NanoMQ MQTT port
iptables -A INPUT -p tcp --dport 1883 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP

# Or temporarily disable HTTP auth in nanomq.conf until upgrade
# Comment out or remove the http_auth configuration section
# auth.http_auth = false