CVE-2025-66023
Heap Use-After-Free in NanoMQ MQTT Bridge Causes DoS
Publication date: 2026-01-01
Last updated on: 2026-02-18
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| emqx | nanomq | to 0.24.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability primarily impacts system availability. Exploitation by a malicious remote MQTT broker can cause NanoMQ to crash or experience memory corruption, resulting in Denial of Service. There are no reported impacts on confidentiality or integrity. [1]
Can you explain this vulnerability to me?
CVE-2025-66023 is a Heap-Use-After-Free (UAF) vulnerability in the MQTT bridge client component of NanoMQ versions prior to 0.24.5. It occurs when NanoMQ acts as a bridge connecting to a remote MQTT broker. A malicious remote broker can exploit this by accepting the connection and immediately sending a malformed packet sequence, causing a crash (Denial of Service) or potential memory corruption. The root cause is improper handling of the MQTT protocol sequence, where the client expects the CONNACK packet to be the first processed packet after connection establishment. Receiving a malformed packet sequence first leads to state confusion and the UAF condition. The issue was fixed by enforcing that CONNACK is always the first packet processed. [1, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring NanoMQ bridge connections for crashes or abnormal behavior when connecting to remote MQTT brokers. Specifically, look for crashes triggered by malformed CONNACK packets sent immediately after connection establishment. Since the issue arises from malformed packet sequences from remote brokers, network traffic analysis tools can be used to capture and inspect MQTT bridge traffic for unexpected or malformed CONNACK packets. However, no specific detection commands are provided in the available resources. [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading NanoMQ to version 0.24.5 or later, which contains the patch enforcing stricter protocol adherence to prevent the vulnerability. As a workaround, validate and ensure the trustworthiness of remote brokers before bridging connections to them, to avoid connecting to malicious brokers that could send malformed packets and trigger the vulnerability. [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability primarily impacts system availability by causing crashes or potential memory corruption when NanoMQ acts as a bridge to a malicious MQTT broker. There are no reported impacts on confidentiality or integrity of data. Therefore, it does not directly affect compliance with common standards and regulations like GDPR or HIPAA, which focus heavily on data confidentiality and integrity. However, the denial of service caused by this vulnerability could indirectly affect availability requirements in some regulatory contexts. [1]