CVE-2026-95844 in Moquette
Summary
by MITRE • 09/23/2026
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, Moquette does not limit the depth of topic names and topic filters before processing them through recursive CTrie insertion and matching operations. A remote client can publish or subscribe with a deeply nested topic, causing a StackOverflowError that disrupts session processing and can deny service to broker clients. This issue is fixed in version 0.18.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in Moquette versions prior to 0.18.1 represents a significant availability risk stemming from insufficient input validation regarding topic name depth. As an open-source lightweight Java MQTT broker, Moquette relies on efficient data structures for managing subscriptions and message routing. The underlying implementation utilizes recursive operations within its CTrie structure to handle the insertion of new topics and the matching of incoming messages against existing subscription filters. This architectural choice introduces a critical flaw when processing topic strings that exceed a certain level of nesting or depth. Because there is no explicit limit imposed on the length or hierarchical complexity of these topic names, the broker fails to detect excessively deep structures before attempting to process them through its recursive algorithms.
From a technical perspective, this lack of boundary checking leads directly to uncontrolled recursion. When a remote client publishes a message with an extremely deeply nested topic name or attempts to subscribe using a similarly complex filter, the Java Virtual Machine is forced to allocate stack frames for each level of nesting encountered during the CTrie traversal and matching process. Since there is no cap on this depth, the call stack rapidly expands beyond its allocated memory limit. This results in a StackOverflowError being thrown within the broker's main processing threads. The exception disrupts the normal flow of session management and message delivery for that specific connection and can potentially destabilize the broader broker instance depending on how exceptions are handled by the surrounding application logic.
The operational impact of this vulnerability is primarily centered around Denial of Service, or DoS conditions. An unauthenticated attacker who has network access to the MQTT port can exploit this flaw by crafting a maliciously deep topic string and sending it to the broker. The resulting StackOverflowError may cause the affected thread to terminate abruptly. If Moquette does not have robust mechanisms for recovering from such errors in its core I/O threads, this could lead to a complete hang or crash of the MQTT service. Consequently, legitimate clients would be unable to publish messages or receive updates, effectively rendering the broker unavailable until it is restarted. This poses a severe risk in environments where continuous availability and reliable message delivery are critical requirements for IoT deployments or real-time data systems.
This vulnerability aligns with CWE-675, which describes operations on multiple resources without sufficient controls, specifically regarding resource exhaustion through uncontrolled recursion depth. It also maps to the MITRE ATT&CK technique T1498, Network Denial of Service, as it involves exploiting a system weakness to disrupt service availability rather than compromising confidentiality or integrity. The root cause is classified under CWE-20, Improper Input Validation, because the application fails to validate and constrain the depth of incoming topic strings before processing them through resource-intensive recursive operations.
To mitigate this risk, organizations running Moquette must upgrade immediately to version 0.18.1 or later, where developers have implemented limits on topic name depth to prevent excessive recursion. For environments that cannot yet patch the software, network-level controls should be considered as a temporary countermeasure. Implementing firewall rules or intrusion prevention systems to inspect MQTT traffic for abnormally long topic strings can help block malicious payloads before they reach the broker application layer. Additionally, configuring JVM parameters such as -Xss to increase stack size may provide marginal resilience against deep recursion but does not address the root cause and is not a recommended primary defense due to potential memory exhaustion risks on the host system.