CVE-2026-22040
Heap Memory Corruption in NanoMQ Broker Causes Crash
Publication date: 2026-03-04
Last updated on: 2026-03-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.6 (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
Can you explain this vulnerability to me?
This vulnerability exists in NanoMQ MQTT Broker version 0.24.6. By generating a specific traffic pattern involving high-frequency publishes combined with rapid reconnects or kick-outs using the same ClientID, along with massive subscribe/unsubscribe jitter, an attacker can reliably trigger heap memory corruption in the Broker process.
This heap memory corruption causes the Broker process to immediately exit with a SIGABRT signal due to an invalid pointer error during memory free operations.
As of the publication date, no patched versions are available to fix this issue.
How can this vulnerability impact me? :
The vulnerability can cause the NanoMQ Broker process to crash unexpectedly, resulting in a denial of service (DoS) condition.
This means that legitimate clients relying on the Broker for message delivery and communication may experience interruptions or loss of service.
Since the Broker exits immediately upon exploitation, it could impact system availability and reliability.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
I don't know
What immediate steps should I take to mitigate this vulnerability?
As of the time of publication, no known patched versions are available for this vulnerability.
Therefore, immediate mitigation steps should focus on avoiding the triggering conditions, such as preventing combined traffic patterns of high-frequency publishes, rapid reconnect/kick-out using the same ClientID, and massive subscribe/unsubscribe jitter.