CVE-2026-102762 in NetX Duoinfo

Summary

by MITRE • 09/29/2026

The NetX Duo MQTT client leaks the packet carrying a malformed PUBLISH message. Each malformed PUBLISH costs one packet, or one chain of packets, from the network driver's receive pool, and nothing returns it. A peer that can deliver a few dozen such messages exhausts the pool and stops all inbound network traffic on the device until it is rebooted.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 09/29/2026

The vulnerability identified in NetX Duo MQTT client represents a critical resource exhaustion flaw stemming from improper memory management during the parsing of incoming MQTT PUBLISH messages. This issue, classified under CWE-401 which denotes missing release of memory after effective use, allows an attacker to trigger a denial-of-service condition by exploiting the internal handling of malformed packets. The NetX Duo stack is designed to process various MQTT control types including CONNECT, SUBSCRIBE, and PUBLISH operations. However, when a client receives a PUBLISH message that fails validation checks or contains structural anomalies defined as malformed within the protocol specification, the library allocates resources from the network driver's receive pool to buffer the incoming data but fails to deallocate these resources upon detection of the error. This lack of cleanup results in a steady leak of packet buffers for every single malformed PUBLISH message processed by the device.

From an operational perspective, this flaw has severe implications for IoT devices relying on MQTT for telemetry or command-and-control communications. The network driver's receive pool is a finite resource shared across all inbound traffic processing. As described, each malformed PUBLISH consumes one packet buffer from this pool without returning it to the available memory space. An adversary capable of sending just a few dozen such crafted messages can rapidly deplete the entire pool. Once the pool is exhausted, the network driver loses its ability to accept new incoming connections or data packets. This effectively halts all inbound network traffic on the affected device, rendering it unresponsive to legitimate MQTT commands, updates, or monitoring requests until the system is manually rebooted to reset the memory state and restore the receive pool capacity.

This attack vector aligns with ATT&CK technique T1499, specifically Endpoint Denial of Service via resource exhaustion, where an attacker overwhelms a target's resources to disrupt service availability. In the context of IoT environments, such vulnerabilities are particularly dangerous because many devices operate in unattended locations or critical infrastructure settings where physical access for rebooting is difficult or impossible without significant operational disruption. The inability to receive new packets means that any security updates, configuration changes, or emergency shutdown commands sent via MQTT will also fail, potentially leaving the device stuck in an insecure or malfunctioning state indefinitely.

Mitigation strategies must focus on both immediate patching and architectural hardening. Organizations should apply vendor-provided patches that address the memory leak by ensuring proper deallocation of packet buffers even when parsing errors occur during PUBLISH message processing. In addition to software updates, network-level defenses such as rate limiting MQTT connections can help mitigate the impact by restricting the number of messages a single peer can send within a given timeframe. Implementing strict input validation at the gateway level before traffic reaches the vulnerable endpoint is also recommended. Furthermore, deploying intrusion detection systems capable of identifying anomalous patterns in MQTT traffic volume and structure can provide early warning indicators for such resource exhaustion attempts, allowing administrators to isolate affected devices before total service failure occurs.

Responsible

Eclipse

Reservation

09/29/2026

Disclosure

09/29/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!