CVE-2025-56352
Denial of Service in tinyMQTT Broker via CONNECT Packet
Publication date: 2026-05-18
Last updated on: 2026-05-18
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| justdoit0910 | tinymqtt | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in tinyMQTT's broker when it mishandles protocol violations during the parsing of CONNECT packets. Specifically, if a CONNECT packet has a zero-length Client ID and the CleanSession flag is set to 0, the broker correctly responds with a CONNACK return code 0x02 (Identifier Rejected) but fails to explicitly close the TCP connection. Because the connection teardown logic is not guaranteed to run, the invalid connection attempts leave sockets open, leading to resource exhaustion on the server.
How can this vulnerability impact me? :
The vulnerability can cause server-side resource exhaustion by leaving many TCP connections open after rejecting invalid CONNECT packets. This accumulation of open sockets consumes file descriptors and memory, potentially causing the MQTT broker to become unresponsive or crash. As a result, an attacker can exploit this to cause a denial of service (DoS), degrading or completely disrupting the availability of the MQTT service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for an unusually high number of half-open TCP connections to the tinyMQTT broker, especially those resulting from CONNECT packets with zero-length Client IDs and CleanSession set to 0.
You can use network and system commands to identify these half-open connections and resource exhaustion symptoms.
- Use netstat or ss to list TCP connections and identify many connections in a half-open state (e.g., SYN_RECV or CLOSE_WAIT) to the MQTT broker port (usually 1883):
- netstat -anp | grep ':1883' | grep -E 'SYN_RECV|CLOSE_WAIT'
- ss -tan state syn-recv '( dport = :1883 )'
- Check the number of open file descriptors used by the tinyMQTT process to detect resource exhaustion:
- ls /proc/$(pidof tinymqtt)/fd | wc -l
- Monitor system logs or broker logs for repeated protocol violations or rejected connections with return code 0x02 (Identifier Rejected).
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Apply any available patches or updates to tinyMQTT that fix the connection teardown logic to ensure TCP connections are properly closed after protocol violations.
- Implement network-level protections such as rate limiting or firewall rules to limit the number of CONNECT attempts with invalid Client IDs from the same source.
- Monitor and limit the number of simultaneous connections to the MQTT broker to prevent resource exhaustion.
- Restart the tinyMQTT broker service periodically to clear accumulated half-open connections and free resources.
- Consider deploying intrusion detection or prevention systems to detect and block malformed MQTT CONNECT packets.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.