CVE-2026-95846 in Moquette
Summary
by MITRE • 09/23/2026
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.publishWill publishes a client's Last-Will message without applying the canWrite authorization and reserved-topic checks used for a normal PUBLISH. A client can configure a Will for a topic that the client is not permitted to write and cause the broker to publish the unauthorized message when the client disconnects unexpectedly. This issue allows unauthorized message injection into restricted topics. 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/23/2026
The vulnerability identified in Moquette, a lightweight Java-based MQTT broker, represents a critical authorization bypass that undermines the integrity of topic-level access controls within the Message Queuing Telemetry Transport protocol implementation. In standard MQTT operations, when a client publishes a message to a specific topic, the broker is required to verify whether the connecting client possesses the necessary write permissions for that target topic before allowing the transmission. This mechanism ensures that only authorized entities can inject data into restricted channels, which is fundamental to maintaining security in IoT and industrial control systems where sensitive telemetry or command-and-control messages are exchanged. The flaw resides specifically within the PostOffice.publishWill method, which handles the delivery of Last-Will messages. These messages serve as a notification mechanism defined by the MQTT specification; they allow clients to specify a message that the broker will automatically publish on their behalf if the client disconnects unexpectedly or loses its connection without sending a proper DISCONNECT packet. This feature is essential for maintaining state awareness in distributed systems, allowing other subscribers to detect when an endpoint has gone offline.
The technical root cause of this vulnerability stems from an inconsistency in how authorization checks are applied between normal message publishing and Last-Will message publication. While the standard PUBLISH flow correctly enforces canWrite authorization rules and reserved-topic restrictions, the code path responsible for executing a client's configured Will message omits these security validations entirely. Consequently, if a malicious or compromised client configures its Last-Will topic to point toward a restricted area of the broker that it does not have explicit write permissions to access, the system will still publish this unauthorized content upon an unexpected disconnection event. This discrepancy creates a direct path for privilege escalation via message injection, as the attacker can leverage the automatic nature of Will messages to bypass manual authorization checks that would otherwise block such actions during active sessions. The impact is particularly severe in environments where topic hierarchies are used to enforce strict separation between different classes of devices or users, allowing an unauthorized actor to pollute sensitive data streams or trigger unintended downstream processes by injecting payloads into protected namespaces.
From a threat modeling perspective, this vulnerability aligns with CWE-269, which describes Improper Privilege Management, as the system fails to properly enforce security boundaries between authenticated but unprivileged clients and restricted resources. It also maps directly to MITRE ATT&CK technique T1530, Data from Information Repositories, specifically in the context of data exfiltration or injection into monitored systems where unauthorized access leads to compromised integrity rather than just confidentiality loss. The operational impact extends beyond simple message pollution; in critical infrastructure scenarios, an attacker could use this flaw to simulate device failures by publishing false offline status messages on behalf of legitimate devices, thereby triggering automated failover mechanisms or alerting systems incorrectly. Alternatively, the injection of malicious payloads into restricted topics can lead to remote code execution if downstream consumers process these inputs without adequate sanitization, effectively turning a simple authorization bypass into a vector for broader system compromise.
Mitigation strategies must prioritize immediate patching and architectural review. The primary remediation is to upgrade Moquette to version 0.18.1 or later, where the developers have corrected the logic in PostOffice.publishWill to apply the same rigorous canWrite and reserved-topic checks that are standard for normal PUBLISH operations. Until an upgrade is feasible, administrators should implement network-level controls such as firewall rules or reverse proxy configurations that restrict direct access to MQTT ports from untrusted networks. Additionally, deploying a secondary validation layer at the application level where subscribers consume messages can provide defense in depth, ensuring that even if unauthorized Will messages are published by the broker, downstream applications validate the source and content before processing. Regular audits of client permissions should also be conducted to ensure that write access is granted on a least-privilege basis, minimizing the potential blast radius if such an authorization bypass were exploited in other contexts within the system architecture.