CVE-2026-85058 in Moquette
Summary
by MITRE • 09/18/2026
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.publishWill publishes a client-controlled Last Will message through publish2Subscribers without invoking the authorizator.canWrite check used by normal PUBLISH paths. When anonymous access is enabled and topic ACLs restrict writes, a remote client can set an ACL-protected topic as the Last Will Topic during CONNECT and perform an abnormal client disconnect, causing the broker to inject attacker-controlled messages into a topic for which the client lacks write permission. This issue is fixed in version 0.18.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Moquette MQTT broker, designed as a lightweight Java-based implementation of the Message Queuing Telemetry Transport protocol, contains a critical authorization bypass vulnerability that allows unauthenticated or low-privileged clients to inject messages into protected topics. This flaw exists within the PostOffice component, specifically in the method responsible for handling Last Will and Testament (LWT) messages. In MQTT protocols, LWTs are pre-defined messages that a broker publishes on behalf of a client if it detects an abnormal disconnection or loss of connectivity. The security architecture relies on strict access control lists to ensure that clients can only publish to topics they have been explicitly granted write permissions for. However, prior to version 0.18.1, the code path executing LWT publication failed to invoke the standard authorization checks used by normal PUBLISH operations.
The technical root cause lies in the divergence between two distinct message handling paths within the broker's architecture. When a client sends a standard MQTT PUBLISH packet, the PostOffice component correctly calls authorizator.canWrite to verify that the authenticated user has permission to write to the target topic. Conversely, when an abnormal disconnect occurs and the broker triggers the Last Will mechanism, it invokes publishWill which subsequently calls publish2Subscribers without performing this same authorization validation. This inconsistency creates a significant security gap where the integrity of access control policies is compromised by bypassing the enforcement layer for automated message injection scenarios.
The operational impact of this vulnerability is severe when anonymous access is enabled on the Moquette instance, as it allows remote attackers to exploit the flaw without needing valid credentials. An attacker can connect to the broker and configure a Last Will Topic that corresponds to an ACL-protected topic where they do not possess write permissions. By then intentionally triggering an abnormal disconnect or allowing their session to timeout, the client forces the broker to execute the LWT logic. Consequently, the broker injects messages controlled by the attacker into the restricted topic, effectively bypassing the intended access controls. This can lead to data integrity issues, unauthorized information disclosure if sensitive topics are targeted, or potential denial of service through message flooding in critical system channels.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as well as CWE-732, concerning Incorrect Permission Assignment for Critical Resource. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior is consistent with techniques involving privilege escalation or unauthorized access to resources, specifically leveraging misconfigured permissions within an application layer protocol. The attack vector is remote and requires no special privileges other than network connectivity to the MQTT broker port, making it particularly dangerous in environments where IoT devices or telemetry systems rely on Moquette for message routing.
To mitigate this risk, organizations running vulnerable versions of Moquette must upgrade immediately to version 0.18.1 or later, which includes patches ensuring that Last Will publications undergo the same rigorous authorization checks as standard publish operations. In addition to upgrading, administrators should enforce strict authentication policies by disabling anonymous access wherever possible, thereby requiring all clients to authenticate before setting LWT parameters. Furthermore, implementing robust network-level firewalls and monitoring for unusual disconnect patterns can provide additional layers of defense against exploitation attempts while ensuring that the broker's security posture remains aligned with industry best practices for message queue integrity.