CVE-2025-56353
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-20

Last updated on: 2026-02-03

Assigner: MITRE

Description
In tinyMQTT commit 6226ade15bd4f97be2d196352e64dd10937c1962 (2024-02-18), a memory leak occurs due to the broker's failure to validate or reject malformed UTF-8 strings in topic filters. An attacker can exploit this by sending repeated subscription requests with arbitrarily large or invalid filter payloads. Each request causes memory to be allocated for the malformed topic filter, but the broker does not free the associated memory, leading to unbounded heap growth and potential denial of service under sustained attack.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-20
Last Modified
2026-02-03
Generated
2026-05-07
AI Q&A
2026-01-20
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
justdoit0910 tinymqtt 2024-02-18
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in tinyMQTT involves a memory leak caused by the broker's failure to validate or reject malformed UTF-8 strings in topic filters. Specifically, the broker accepts and stores arbitrary byte sequences as topic filters without checking if they are well-formed UTF-8 strings as required by the MQTT v3.1.1 specification. An attacker can exploit this by sending repeated subscription requests with large or invalid filter payloads, causing the broker to allocate memory for each malformed topic filter without freeing it. This leads to unbounded memory growth and can eventually crash the broker under sustained attack. [1]


How can this vulnerability impact me? :

The vulnerability can lead to denial of service by exhausting the broker's memory resources. An attacker can repeatedly send malformed subscription requests that cause the broker to allocate memory without releasing it, resulting in unbounded heap growth. This can cause the broker to crash or become unresponsive. Additionally, related issues with half-open connections can exhaust server resources like file descriptors and memory, further degrading service availability and stability. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for repeated malformed SUBSCRIBE packets with invalid or arbitrarily large UTF-8 topic filters being sent to the tinyMQTT broker. Additionally, detection can involve checking for an unusually high number of half-open TCP connections where the ClientId is zero-length and CleanSession is 0, as these connections are not properly closed by the broker. Network packet capture tools like tcpdump or Wireshark can be used to capture and analyze MQTT traffic for malformed SUBSCRIBE packets. Commands such as `tcpdump -i <interface> port 1883 -w capture.pcap` can capture MQTT traffic (default MQTT port 1883). Then, analyzing the capture for malformed UTF-8 topic filters or repeated SUBSCRIBE packets can help detect exploitation attempts. On the system side, monitoring the broker's memory usage and the number of open TCP connections (e.g., using `netstat -anp | grep <broker_pid>` or `ss -s`) can indicate resource exhaustion consistent with this vulnerability. [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include restricting or filtering incoming MQTT SUBSCRIBE packets to ensure topic filters conform to valid UTF-8 encoding before they reach the broker, if possible. Limiting the rate of SUBSCRIBE requests from clients can reduce the impact of repeated malformed packets. Additionally, monitoring and limiting the number of half-open TCP connections to the broker can help prevent resource exhaustion. Applying any available patches or updates to tinyMQTT that address these issues is critical once released. As a temporary measure, restarting the broker periodically may help recover from memory leaks, but this does not prevent exploitation. Network-level protections such as firewall rules or intrusion detection systems configured to detect and block malformed MQTT packets can also help mitigate attacks. [1]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart