CVE-2026-95845 in Moquette
Summary
by MITRE • 09/23/2026
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, the broker does not enforce a maximum length for pending per-session message queues. When a fast publisher sends messages to a slow subscriber whose in-flight window is full, queued messages can accumulate without bound in memory or persistent storage. Remote clients can use this condition to exhaust broker resources and cause a denial of service. This issue is fixed in version 0.18.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The Moquette MQTT broker, a lightweight Java-based implementation designed for Internet of Things communications, contains a critical resource management flaw that impacts system stability under specific load conditions. The vulnerability stems from the absence of an enforced upper limit on pending per-session message queues within the broker architecture. In standard Message Queuing Telemetry Transport operations, when a publisher transmits data at a rate exceeding the subscriber's processing capacity or network bandwidth, messages are temporarily stored in memory or persistent storage until they can be delivered. This mechanism is essential for ensuring reliable delivery to offline or slow clients but requires strict boundary controls to prevent abuse.
The technical flaw lies in the broker's failure to implement maximum length constraints on these pending queues. When a fast publisher continuously sends messages to a slow subscriber whose in-flight window is already full, the broker lacks the logic to reject new incoming messages for that specific session or topic. Consequently, queued messages accumulate without bound, consuming increasing amounts of system memory and disk space over time. This unbounded growth occurs because the broker prioritizes message retention for reliability over resource protection, creating a scenario where legitimate operational parameters are exploited by excessive data volume rather than malicious payload content.
From an operational perspective, this vulnerability enables remote clients to execute a denial-of-service attack against the MQTT infrastructure. By maintaining a persistent connection with a slow subscriber and continuously publishing high-volume traffic, an attacker can exhaust available system resources on the broker host. This resource exhaustion leads to degraded performance for other legitimate users, potential crashes of the Java virtual machine due to out-of-memory errors, or complete unavailability of the messaging service. The impact is particularly severe in environments where brokers are deployed with limited memory allocations or when managing a large number of concurrent sessions, as the cumulative effect can destabilize the entire system rather than just affecting individual client connections.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting through unbounded resource accumulation in message queues. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1498, Network Denial of Service, where the attacker leverages protocol mechanics to overwhelm system capacity rather than exploiting code execution flaws. The attack vector is remote and requires no authentication if anonymous access or weak credentials are enabled for publishing, making it a significant risk in public-facing IoT deployments.
The issue has been addressed in Moquette version 0.18.1 through the implementation of strict limits on pending message queues per session. Administrators operating older versions should upgrade immediately to mitigate this risk. In addition to upgrading, organizations can implement network-level rate limiting or deploy reverse proxies that enforce maximum payload sizes and connection rates before traffic reaches the broker. Monitoring memory usage trends for MQTT sessions can also provide early detection of such resource exhaustion attempts, allowing for proactive intervention before system stability is compromised.