CVE-2025-56352: tinyMQTT Broker DoS Vulnerability

CVE-2025-56352 Overview

CVE-2025-56352 is a resource exhaustion vulnerability in tinyMQTT, an open-source MQTT broker implementation. The flaw exists in commit 6226ade15bd4f97be2d196352e64dd10937c1962 dated 2024-02-18. The broker mishandles protocol violations during CONNECT packet parsing. When a client sends a CONNECT packet with a zero-length Client ID while CleanSession is set to 0, the broker replies with CONNACK return code 0x02 (Identifier Rejected) but fails to close the underlying TCP connection. Repeated invalid CONNECT attempts accumulate open file descriptors and memory, leading to denial of service. The issue is tracked under [CWE-400] Uncontrolled Resource Consumption.

Critical Impact

Remote unauthenticated attackers can exhaust broker file descriptors and memory by repeatedly sending malformed CONNECT packets, causing denial of service.

Affected Products

• tinyMQTT broker at commit 6226ade15bd4f97be2d196352e64dd10937c1962 (2024-02-18)
• Downstream forks or builds incorporating the unpatched CONNECT handling logic
• MQTT services exposing the affected broker to untrusted networks

Discovery Timeline

• 2026-05-18 - CVE-2025-56352 published to NVD
• 2026-05-18 - Last updated in NVD database

Technical Details for CVE-2025-56352

Vulnerability Analysis

The vulnerability resides in the CONNECT packet handling path of the tinyMQTT broker. The MQTT 3.1.1 specification states that a broker receiving a CONNECT with a zero-length Client ID and CleanSession=0 must reject the client with CONNACK return code 0x02 and close the network connection. The tinyMQTT implementation issues the CONNACK response but does not invoke the socket teardown routine on the rejection path. The surrounding cleanup logic is conditional and is not guaranteed to execute when the connection is rejected at this early validation stage.

Each rejected client therefore leaves an established TCP socket and the associated broker-side connection state allocated. An attacker who scripts repeated CONNECT attempts steadily consumes file descriptors, kernel socket buffers, and heap memory used to track partial connections. When the broker exhausts its file descriptor limit, it can no longer accept legitimate clients, completing the denial of service condition.

Root Cause

The root cause is missing explicit connection teardown on a protocol violation branch. The CONNECT validation code reports the protocol error to the client but returns without calling the connection close path. Because no destructor or finalizer is bound to the partial connection object, the socket remains open until the operating system enforces a timeout.

Attack Vector

The attack is performed over the network against any exposed tinyMQTT listener, typically TCP port 1883. No authentication or user interaction is required. An attacker repeatedly opens TCP sessions and sends CONNECT packets with a zero-length Client ID and the CleanSession flag cleared. Each packet consumes broker resources without releasing them, and the attack scales linearly with connection rate. Technical details and a proof of concept are available in the GitHub Issue Discussion and the GitHub PoC Resource.

Detection Methods for CVE-2025-56352

Indicators of Compromise

• High volume of inbound TCP connections to MQTT port 1883 originating from a small set of source IP addresses
• Broker logs showing repeated CONNACK responses with return code 0x02 (Identifier Rejected)
• Steadily increasing file descriptor counts and resident memory in the tinyMQTT process without a matching client population
• Established TCP sessions to the broker that remain open after a CONNACK rejection without an orderly FIN or RST

Detection Strategies

• Inspect MQTT traffic with a network sensor or broker plugin to flag CONNECT packets with a zero-length Client ID and CleanSession set to 0
• Correlate CONNACK 0x02 events with sockets that persist beyond a short threshold to identify stuck connections
• Baseline normal MQTT client behavior and alert on sudden spikes of identifier rejection events

Monitoring Recommendations

• Track lsof or /proc/<pid>/fd counts for the broker process and alert on rapid growth
• Export broker metrics such as active connection count, rejected connection count, and heap usage to a time-series monitoring system
• Forward broker and host telemetry to a centralized data lake for retrospective analysis of resource exhaustion patterns

How to Mitigate CVE-2025-56352

Immediate Actions Required

• Restrict network exposure of the tinyMQTT broker to trusted clients using firewall rules or a VPN
• Apply per-source-IP connection rate limits at the network edge to blunt repeated CONNECT floods
• Reduce operating system nofile limits cautiously while monitoring for legitimate client impact, and configure short TCP idle timeouts on the broker host
• Audit broker logs for prior CONNACK 0x02 patterns indicating attempted exploitation

Patch Information

No vendor-issued patch has been referenced in the NVD entry at the time of publication. Operators should track the upstream GitHub Issue Discussion for fix status. A code-level remediation must ensure the CONNECT handler explicitly closes the TCP socket and frees connection state immediately after sending CONNACK 0x02, rather than relying on later cleanup logic.

Workarounds

• Place a hardened MQTT-aware proxy in front of tinyMQTT to validate CONNECT packets and drop those with a zero-length Client ID and CleanSession set to 0
• Replace tinyMQTT with a production-grade broker such as Mosquitto or EMQX where exposure to untrusted networks is required
• Implement a watchdog that restarts the broker process when file descriptor or memory usage exceeds defined thresholds

# Example iptables rate limit for MQTT port 1883
iptables -A INPUT -p tcp --dport 1883 -m conntrack --ctstate NEW \
  -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -m conntrack --ctstate NEW -j DROP