CVE-2026-85724: Moquette pattern ACL wildcard injection allows cross-tenant authorization bypass

Published Sep 23, 2026
·
Updated

Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, when pattern-based ACL rules are configured, AuthorizationsCollector.canDoOperation substitutes client ID and username values directly into rules containing %c or %u and then treats the result as an MQTT topic filter. A client that uses + or # in either identity can broaden the substituted filter and gain cross-tenant read and write access. A # identity can also produce an invalid filter that triggers a NullPointerException in Topic.match and disrupts session processing. This issue is fixed in version 0.18.1.

Other sources

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 sensormeta 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.

GitHub

Affected Software

1 affected componentFixes available
maven/io.moquette:moquette-broker<=0.18.0
0.18.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/io.moquette:moquette-broker to a version that resolves this vulnerability.

    Fixed in 0.18.1
  2. Upgrade

    Upgrade Moquette to a version that resolves this vulnerability.

    Fixed in 0.18.1
  3. Configuration

    Use separate H2 namespaces for queues and queue metadata so client IDs cannot collide with another client's metadata map.

    Moquette H2 persistent storage queue namespace isolation = separate namespaces
  4. Configuration

    Fail closed when the authenticator or authorizator class fails to load; do not fall back to PermitAll or AcceptAll.

    Moquette authentication and authorization class loading failure behavior = fail closed
  5. Configuration

    Add resource caps for connections, queues, retained messages, topic aliases, and the interceptor queue, and use bounded session expiry.

    Moquette broker resources resource limits and session expiry = bounded
  6. Configuration

    Apply canWrite and reserved-topic authorization checks to Will publishes like normal PUBLISH operations.

    Moquette Will publishing authorization = apply normal PUBLISH authorization
  7. Compensating control

    At CONNECT, reject clientId and username values containing MQTT wildcard characters + or #, and reject / when it is structurally significant; expand %c and %u as literal tokens rather than wildcard-matched topic-filter content.

  8. Compensating control

    Harden SessionEventLoop by catching Throwable and adding restart supervision so an uncaught exception cannot wedge every co-located client.

  9. Compensating control

    Validate malformed $share subscription filters before processing them, including filters that could cause extractShareName to throw StringIndexOutOfBoundsException.

Event History

Sep 23, 2026
Advisory Published
via GitHub·04:11 PM
Data Sourced
via GitHub·04:11 PM
DescriptionSeverityAffected Software
CVE Published
via MITRE·04:29 PM
Data Sourced
via MITRE·04:29 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Are deployments using anonymous MQTT access exposed to the ACL bypass?

The broker is described as allowing anonymous clients by default, so untrusted clients can connect unless access has been restricted. The cross-tenant ACL bypass specifically requires pattern-based ACL rules using client ID or username substitution.

2

What does an attacker need to bypass tenant ACLs?

An attacker needs to connect as an MQTT client and supply a client ID containing MQTT wildcard characters such as + or #. Those characters are substituted into pattern ACL rules without validation, allowing a rule such as sensor/%c/# to be broadened to sensor/+/#.

3

What access can the ACL issue provide?

The described impact is cross-tenant read and write access where affected pattern ACLs are configured. The reported impact ceiling is authorization or ACL bypass, denial of service, and cross-session integrity issues; remote code execution is not claimed.

4

Which source revision was audited?

The audit covered the broker/ module at commit da7f719a6bab9829d520b5838e13ea7b1f9be3ef. No affected or fixed release versions are provided in the available data.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203