CVE-2026-95847 in Moquette
Summary
by MITRE • 09/23/2026
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, H2PersistentQueue derives a session's message-map name as queue_ plus the client ID and its metadata-map name as queue_ plus the client ID plus _meta. A durable session whose client ID ends in _meta can therefore make its message map collide with another client's metadata map. The colliding sessions read and write the same H2 MVStore map with incompatible value types, which can corrupt queue head and tail data and cause message loss, misdelivery, failed queue reloads, or exposure of queued content across sessions. 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 Moquette MQTT broker, a lightweight Java-based implementation designed for Internet of Things messaging scenarios, contains a critical flaw in its persistent session management logic prior to version 0.18.1. The vulnerability stems from an insufficiently unique naming convention used by the H2PersistentQueue component when deriving identifiers for internal data structures within the underlying H2 MVStore database engine. Specifically, the system constructs message-map names using the prefix queue_ concatenated with the client identifier, while metadata maps are named using the same prefix followed by the client ID and a _meta suffix. This design assumes that no two valid MQTT client IDs will result in overlapping or ambiguous file paths within the storage layer, an assumption that is violated under specific conditions involving durable sessions.
The core technical flaw arises when a malicious or misconfigured client registers with a durable session using a client identifier that ends with the string _meta. In such cases, the system generates a metadata map name for this client that matches the message-map name generated by another legitimate client whose ID is identical to the first client's ID minus the suffix. For example, if Client A uses the ID test_client_meta and Client B uses the ID test_client, their respective internal storage maps collide because both resolve to queue_test_client_meta in certain lookup contexts or cause type conflicts when accessing the same underlying MVStore map entry. This collision results in two distinct sessions attempting to read and write incompatible value types to the same physical data structure within the H2 database.
The operational impact of this vulnerability is severe, leading to potential denial of service through data corruption and significant integrity failures. Because the message queue head and tail pointers are stored within these colliding maps, concurrent access by conflicting sessions can corrupt the structural integrity of the queues. This corruption manifests as immediate message loss for affected clients, misdelivery where messages intended for one session appear in another, or complete failure to reload queued data upon broker restarts. Furthermore, there is a risk of information disclosure, as improperly isolated storage allows one client potentially access to content queued by another, violating the fundamental isolation guarantees expected in multi-tenant MQTT deployments.
From a classification perspective, this vulnerability aligns with CWE-610, which describes externally controlled reference to a resource that can lead to unintended behavior due to insufficient uniqueness or collision handling. It also relates to CWE-278 regarding incorrect defaults for security-relevant configuration items if the naming convention was intended as an access control mechanism. In terms of adversary tactics, this flaw could be leveraged in ATT&CK technique T1496, Resource Hijacking, by causing service degradation or data corruption within a critical messaging infrastructure component.
To mitigate this risk, organizations running Moquette must upgrade to version 0.18.1 or later immediately. This release corrects the naming logic to ensure that message maps and metadata maps remain distinct even when client identifiers contain suffixes like _meta. Until an upgrade is performed, administrators should enforce strict validation on MQTT client IDs at the network perimeter using firewalls or reverse proxies to reject any connection attempts where the client ID ends with _meta for durable sessions. Additionally, reviewing existing deployments for clients utilizing such naming conventions can help identify affected systems before applying patches.