CVE-2026-85058: Missing Authorization in Moquette MQTT Broker Last Will and Testament Feature

Moquette is a lightweight, Java-based MQTT broker widely utilized in resource-constrained contexts, enterprise Java integration layers, and IoT communication structures. The broker implements the standard MQTT protocol, which supports a reliability feature known as Last Will and Testament (LWT). The LWT mechanism allows a connecting client to specify an administrative or operational topic and a payload that the broker must publish if the client's connection terminates unexpectedly. This mechanism acts as an automated state-reporting function for distributed nodes.

In standard operating modes, Moquette uses an access control list (ACL) policy engine represented by the IAuthorizatorPolicy interface to restrict client publish and subscribe operations. These ACL policies are evaluated whenever a client issues an MQTT PUBLISH control packet to prevent unauthorized message injection. This security model ensures that write-restricted or anonymous clients cannot post data to critical command and control channels.

However, in versions of Moquette prior to 0.18.1, the message-routing logic completely bypassed authorization checks when executing the publication of a client's LWT. While standard publications are strictly vetted against ACL parameters, the LWT execution workflow did not query the authorization policy engine. Consequently, a client with restricted or non-existent write permissions could register an unauthorized topic as its LWT during the connection handshake and force the broker to publish to it by abruptly dropping the connection.

The root cause of CVE-2026-85058 is located in the session teardown handling logic within the core routing class broker/src/main/java/io/moquette/broker/PostOffice.java. When a client connects using an MQTT CONNECT packet, it submits its LWT parameters, including the target topic and the payload. The broker parses this packet and stores the LWT parameters inside the session repository database. Critically, Moquette does not perform authorization checks at the time of connection because no message has been published yet.

When a client disconnects abnormally, the network interface layer triggers a session teardown sequence. This sequence invokes the PostOffice.fireWill() method, which subsequently calls PostOffice.publishWill(ISessionsRepository.Will will). The broker builds an internal MqttPublishMessage structure from the stored session Will parameters.

In vulnerable versions, the compiled message was passed directly to the subscription distribution subsystem via publish2Subscribers(). Because the broker did not evaluate authorizator.canWrite() before dispatching the message, any registered LWT was successfully routed. The vulnerability is characterized as an architectural missing authorization flaw (CWE-862), where the broker trustingly processes internally generated publish events without validating the initial source's authorization privileges.

To understand the vulnerability, look at the vulnerable implementation of the publishWill method in PostOffice.java prior to the patch. The method was structured to construct the message and immediately distribute it to matching subscribers:

// Vulnerable Code Path in PostOffice.java (Pre-0.18.1)
private void publishWill(ISessionsRepository.Will will) {
    // ... builds the MqttPublishMessage willPublishMessage from the stored Will ...
    MqttPublishMessage willPublishMessage = publishBuilder.build();
 
    // CRITICAL: The broker directly distributes the message without querying the authorizator
    publish2Subscribers(WILL_PUBLISHER, messageExpiryInstant, willPublishMessage);
}

The patch introduced in commit f5a323fe782d1505c0097498cb22eb6ec6c96973 addresses this by inserting an explicit access control validation check. If the check fails, the message is dropped and an error log is generated:

// Patched Code Path in PostOffice.java (0.18.1)
private void publishWill(ISessionsRepository.Will will) {
    // ... builds the MqttPublishMessage willPublishMessage from the stored Will ...
    MqttPublishMessage willPublishMessage = publishBuilder.build();
 
    // PATCH: Validate write access on the target LWT topic before distributing
    if (!authorizator.canWrite(Topic.asTopic(will.topic), "", WILL_PUBLISHER)) {
        LOG.error("client is not authorized to publish Last Will Testament on topic: {}", will.topic);
        return;
    }
    publish2Subscribers(WILL_PUBLISHER, messageExpiryInstant, willPublishMessage);
}

While this patch successfully mitigates the immediate bypass, security teams must note that the authorization query is evaluated using the hardcoded static identifier WILL_PUBLISHER and an empty string for the username parameter. This decoupling means that custom authorization policies must explicitly handle the WILL_PUBLISHER client ID to avoid locking out legitimate system notifications or accidentally permitting unauthorized operations if the policy engine treats empty strings or system identities permissively.

Exploitation of CVE-2026-85058 is highly reliable because it requires no complex memory alignment, advanced network positioning, or authentication credentials. The attack complexity is low and can be executed over standard TCP/IP. The attacker only needs network reachability to the Moquette broker instance.

First, the attacker establishes a connection to the broker. If anonymous access is permitted, the attacker connects without credentials. In the initial MQTT CONNECT control packet, the attacker registers a Will topic pointing to a restricted path, such as an administration or control channel, along with an arbitrary payload. The broker accepts the registration and associates it with the new session.

Second, the attacker triggers the execution of the LWT by forcing an unclean disconnection. This is achieved by closing the network socket or sending a TCP Reset (RST) packet. The attacker must avoid sending a clean MQTT DISCONNECT packet, as doing so instructs the broker to discard the registered LWT. Upon detecting the abrupt network loss, the broker executes the unvetted LWT and publishes the attacker's payload directly to the restricted topic.

The impact of this vulnerability is significant in environments where MQTT serves as a messaging backplane for sensitive or automated systems. By exploiting this flaw, write-restricted clients can inject arbitrary payloads into restricted topics, leading to unauthorized state modification, data injection, or spoofing. In industrial control or IoT deployments, this could allow unauthorized actors to issue control commands to downstream devices subscribing to restricted administrative channels.

The CVSS v3.1 base score is assessed at 7.5 (High), with the vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. The exploitability subscore is 3.9, reflecting that the attack requires no user interaction, operates over the network, and can be executed with zero initial privileges. The impact is limited to integrity, with no immediate confidentiality or availability compromise resulting from the bypass itself.

While there is no active exploitation reported in the wild, the public availability of the functional regression test suite makes the vulnerability easy to weaponize. Security operations teams should prioritize remediation of this flaw due to the trivial nature of its execution.

Moquette version 0.18.1 resolves several other critical security issues in addition to the LWT authorization bypass. These sibling vulnerabilities highlight the importance of upgrading the broker component:

• Pattern-ACL Wildcard Injection (GHSA-9jjc-fw8x-fmwx sibling fix): Moquette failed to validate whether the client-provided clientID or username contained MQTT wildcard characters (+ or #). A client connecting with a clientID of + could match expanded rules like /sensor/+/data, bypassing tenant boundaries and gaining cross-tenant access.
• Remote DoS via Null Username in Pattern ACLs: When pattern ACLs were active, anonymous clients connecting with a null username triggered a NullPointerException inside String.replace() during policy evaluation. This unhandled exception escaped the session loop, terminating the worker thread and denying service to other connected clients.
• Persistent Queue Namespace Collision: Moquette used H2's MVStore to persist client queues, naming the maps based on the client ID. Attackers could register a client ID that overlapped with another client's metadata map, leading to durable data loss or cross-session message leakage.
• Malformed Shared Subscription Crash: Clients subscribing to a malformed MQTT v5 shared subscription triggered a StringIndexOutOfBoundsException during parsing, leading to uncaught exceptions that crashed command handling on the shared session event loop.
• Recursion-based Stack Overflow: Highly nested topic paths containing thousands of segments triggered a recursive loop inside the broker's concurrent trie, resulting in a StackOverflowError that crashed the JVM instance.

The primary recommendation is to upgrade Moquette to version 0.18.1 or higher. This version addresses the LWT authorization bypass, resolves the secondary denial of service bugs, and patches the concurrent trie recursion issues. Upgrading represents the most comprehensive path to securing the broker infrastructure.

If upgrading is not immediately possible, security teams should implement temporary workarounds to reduce the attack surface. First, disable anonymous access to restrict connection capabilities to authenticated entities. This prevents completely unauthorized actors from registering LWT packets:

# moquette.conf
allow_anonymous false

Second, review all custom implementations of IAuthorizatorPolicy. Ensure that policy logic does not grant implicit write access to empty usernames or the hardcoded WILL_PUBLISHER client ID. Finally, implement network-level rate limiting on connection churn to mitigate automated exploitation attempts that rely on rapid connect and disconnect sequences.