CVE-2026-95844

Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, Moquette does not limit the depth of topic names and topic filters before processing them through recursive CTrie insertion and matching operations. A remote client can publish or subscribe with a deeply nested topic, causing a StackOverflowError that disrupts session processing and can deny service to broker clients. This issue is fixed in version 0.18.1.

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.

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.

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.

Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, when a configured authenticator or authorizator class cannot be loaded, Server.initializeAuthenticator and Server.initializeAuthorizatorPolicy treat the failure as though no custom class was configured and fall back to AcceptAllAuthenticator or PermitAllAuthorizatorPolicy. A misspelled class name, missing dependency, constructor failure, or classpath problem can therefore start the broker with authentication or authorization disabled even though the operator configured those controls. This issue is fixed in version 0.18.1.

moquette is reachable by untrusted MQTT clients (anonymous by default), so every byte from any client, including pre-authentication, is untrusted. This is a memory-safe JVM: the ceiling is authorization/ACL bypass + denial of service + cross-session integrity, not RCE (I did not find one and do not claim one). Audited at commit da7f719a6bab9829d520b5838e13ea7b1f9be3ef, module broker/.

What a connecting client can do

1. (Critical) Bypass pattern-based ACLs across tenants. In AuthorizationsCollector.canDoOperation (AuthorizationsCollector.java:116-131, esp. line 123) the clientId/username is substituted raw into a pattern ACL rule and then wildcard-matched, and the clientId is never validated for MQTT wildcard characters +/# at CONNECT (MQTTConnection.processConnect):

Topic substitutedTopic = new Topic(auth.topic.toString().replace("%c", client).replace("%u", username)); if (topic.match(substitutedTopic)) return true;

A client that connects with clientId + turns sensor/%c/# into the filter sensor/+/#, gaining cross-tenant read AND write. (Precondition: pattern ACL rules configured — a common multi-tenant setup.)

2. (High) Crash the whole broker. SessionEventLoop (SessionEventLoop.java:40-54) catches only InterruptedException and is never restarted (SessionEventLoopGroup), so any uncaught exception on it wedges every co-located client. Trivially reachable inputs: malformed $share/grp SUBSCRIBE (SharedSubscriptionUtils.extractShareName -> StringIndexOutOfBoundsException), deeply nested topic (CTrie recursion -> StackOverflowError), and ACL NPE below. Unbounded subscriptions / retained / in-flight / topic-alias / interceptor state (BrokerInterceptor uses an unbounded queue) also allow OOM; durable stores allow disk exhaustion.

3. (High) NPE in ACL sink on clientId # (invalid filter sensor/#/# -> null tokens -> Topic.match NPE at Topic.java:173).

4. (High) Will-message authorization bypass. Last-Will topic is published (PostOffice.publishWill) without canWrite/reserved-topic checks used for normal PUBLISH.

5. (Medium) Cross-session durable corruption. H2PersistentQueue opens queue_"+clientId and queue_"+clientId+"_meta; client id sensor_meta collides with victim sensor metadata map -> corrupts head/tail.

6. (Medium) Fail-open if authenticator/authorizator class fails to load -> PermitAll/AcceptAll (Server.java:483-531).

Proof of concept

Source-only, no network; PoCs run on JDK 17:

• PoCPatternAcl — clientId + gains cross-tenant read/write; clientId # triggers NPE
• PoCSharedSubCrash — extractShareName("$share/grp") throws StringIndexOutOfBoundsException
• PoCMapCollision — H2 MVStore collision overwrites victim metadata pointer

Impact

Cross-tenant eavesdropping and injection, whole-broker DoS, unauthorized Will publishes, and cross-session durable corruption.

Remediation

1. Reject clientId/username containing +/# (and / if structural) at CONNECT; expand %c/%u as literal tokens.
2. Harden SessionEventLoop (catch Throwable + restart supervision) and validate $share filters.
3. Apply authorization to Will publishes like normal PUBLISH.
4. Add resource caps (connections, queues, retained, aliases, interceptor queue) + bounded session expiry.
5. Separate H2 namespaces and fail closed on auth-class load failure.