CVE-2026-32135
Received Received - Intake
Heap Buffer Overflow in NanoMQ REST API Allows Remote Exploitation

Publication date: 2026-04-20

Last updated on: 2026-04-22

Assigner: GitHub, Inc.

Description
NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. Versions prior to 0.24.11 have a remotely triggerable heap buffer overflow in the `uri_param_parse` function of NanoMQ's REST API. The vulnerability occurs due to an off-by-one error when allocating memory for query parameter keys and values, allowing an attacker to write a null byte beyond the allocated buffer. This can be triggered via a crafted HTTP request. Version 0.24.11 patches the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-20
Last Modified
2026-04-22
Generated
2026-05-07
AI Q&A
2026-04-21
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
emqx nanomq to 0.24.11 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-122 A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not specify any direct impact of the CVE-2026-32135 vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

CVE-2026-32135 is a heap buffer overflow vulnerability in the NanoMQ MQTT Broker's REST API, specifically in the `uri_param_parse` function. The issue arises from an off-by-one error during memory allocation for URL query parameter keys and values. The function allocates memory based on the length of the parameter string without accounting for the null terminator, causing a one-byte overflow when the null terminator is written. This vulnerability can be triggered remotely by sending a crafted HTTP request with query parameters to the NanoMQ REST API.

Additionally, the vulnerability involves improper handling of URL decoding in the REST API, where the URLDecoding function reads beyond allocated buffers due to insufficient boundary checks, leading to out-of-bounds memory reads and writes. This can cause the NanoMQ broker to crash or behave unexpectedly.


How can this vulnerability impact me? :

This vulnerability can lead to a denial of service (DoS) condition by crashing the NanoMQ broker when it processes specially crafted HTTP requests. The heap buffer overflow corrupts memory, causing the HTTP management API to close connections unexpectedly and making the service unavailable.

In some cases, depending on the heap layout and adjacent data structures, this vulnerability could potentially be exploited for remote code execution (RCE), allowing an attacker to execute arbitrary code on the affected system.


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

This vulnerability can be detected by sending crafted HTTP requests to the NanoMQ REST API endpoints, particularly targeting the query parameters or the /api/v4/get_file endpoint on port 8081.

A practical detection method involves using curl commands to send requests with specific query parameters that trigger the heap-buffer-overflow, such as unencoded or malformed URL parameters.

  • Example curl command to test the vulnerability: curl "http://localhost:8081/api/v4/brokers?a&b" -u admin:public

If the system is vulnerable, the NanoMQ broker may crash or the HTTP connection may close unexpectedly after such requests, indicating the presence of the heap-buffer-overflow.

Additionally, monitoring for crashes or service unavailability on the HTTP management API port (8081) after sending such requests can help detect exploitation attempts.


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to upgrade NanoMQ to version 0.24.11 or later, where the vulnerability has been patched.

The patch includes disabling the vulnerable /get_file API endpoint and revising the URL decoding function to safely handle input and prevent out-of-bounds memory access.

If upgrading immediately is not possible, consider disabling or restricting access to the HTTP management API, especially the /api/v4/get_file endpoint on port 8081, to prevent exploitation.

Monitor your NanoMQ service for crashes or unexpected behavior and apply strict input validation or firewall rules to block suspicious HTTP requests targeting the REST API.


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