What is the CVSS score of CVE-2025-56352?

CVE-2025-56352 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Which versions of tinyMQTT are affected by CVE-2025-56352?

CVE-2025-56352 affects tinyMQTT message brokers, allowing unauthenticated remote attackers to trigger denial-of-service conditions by exhausting server resources through repeated malformed connection…

How to fix or mitigate CVE-2025-56352?

Within 24 hours, identify all systems running tinyMQTT broker and determine if any are running commit 6226ade from February 2024 or earlier; prioritize production systems handling critical MQTT traffic. Within 7 days, implement connection rate limiting to restrict repeated CONNECT attempts from individual sources, configure OS-level file descriptor and memory limits to prevent resource starvation, and enable monitoring with alerts for malformed packets and connection failures. Within 30 days, monitor the tinyMQTT project for a patched release and plan the upgrade; until a patch is available, restrict MQTT broker network access to trusted clients via firewall rules and implement automated restart mechanisms triggered by resource-usage thresholds.

tinyMQTT CVE-2025-56352

EUVD-2025-209887 HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-05-18 mitre

GHSA-m5jh-ppcv-76xr

Denial Of Service N A

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

Unauthenticated network-reachable CONNECT flood with low complexity and no user interaction; impact is availability-only (socket/memory exhaustion), so C:N/I:N/A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 23, 2026 - 18:06 vuln.today

CVE Published

May 18, 2026 - 00:00 cve.org

HIGH 7.5

CVE Published

May 18, 2026 - 00:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

In tinyMQTT commit 6226ade15bd4f97be2d196352e64dd10937c1962 (2024-02-18), the broker mishandles protocol violations during CONNECT packet parsing. When receiving a CONNECT packet with a zero-length Client ID while CleanSession is set to 0, the broker correctly replies with a CONNACK return code 0x02 (Identifier Rejected) but fails to explicitly close the TCP connection. Since the surrounding connection teardown logic is not guaranteed to execute, each such invalid CONNECT attempt leaves the underlying socket open. Repeated attempts cause server-side resource exhaustion due to accumulating file descriptors and memory usage, potentially resulting in denial of service.

AnalysisAI

Denial of service in the tinyMQTT broker (commit 6226ade, 2024-02-18) lets remote unauthenticated clients exhaust server resources by repeatedly sending malformed CONNECT packets. When a CONNECT arrives with a zero-length Client ID and CleanSession=0, the broker sends the correct CONNACK 0x02 (Identifier Rejected) but never closes the TCP socket, leaking a file descriptor and memory on every attempt until the process is starved. Publicly available exploit code exists (a resource-exhaustion PoC is attached to the NVD reference), but there is no public exploit identified as used in attacks, EPSS is very low (0.05%), and it is not in CISA KEV.

Technical ContextAI

tinyMQTT is a small C-based MQTT broker implementing the MQTT protocol's connection handshake. The MQTT 3.1.1 specification states that a broker may accept a zero-length Client ID only when CleanSession=1 (assigning a unique ID itself); a zero-length ID with CleanSession=0 is a protocol violation that must be rejected with CONNACK return code 0x02. tinyMQTT rejects it correctly at the protocol level but its connection teardown path does not guarantee the underlying socket is closed after that rejection, so the descriptor and its associated buffers persist. This is a classic CWE-400 (Uncontrolled Resource Consumption) defect rooted in a resource-cleanup/lifecycle bug rather than a memory-corruption flaw. The CPE data is uninformative (cpe:2.3:a:n/a:n/a:*), so affected scope is defined by the referenced GitHub commit rather than a structured product identifier.

RemediationAI

No vendor-released patch or tagged version is identified at time of analysis, as tinyMQTT is an unversioned source-only project; track the upstream issue at https://github.com/JustDoIt0910/tinyMQTT/issues/19 for a fix. The concrete code fix is to explicitly close() the client socket and free its connection state immediately after sending CONNACK 0x02 in the CONNECT-handling path, rather than relying on later teardown logic. Until an upstream fix is confirmed, compensating controls include placing the broker behind a reverse proxy or firewall that restricts the MQTT listener (default TCP 1883) to trusted clients only - trade-off: breaks open/public broker use cases; enforcing per-source connection rate limits and OS-level file-descriptor limits (ulimit) so a flood degrades gracefully rather than crashing - trade-off: legitimate high-connection clients may be throttled; and monitoring the broker's open file-descriptor count to alert on leakage. Given the project's hobby status, migrating production workloads to a maintained broker such as Mosquitto or EMQX is the most durable option. Additional third-party analysis is at https://vuldb.com/vuln/364480.