CVE-2026-85058: Moquette: Missing Authorization in io.moquette:moquette-broker

Published Sep 18, 2026
·
Updated

Summary

Moquette MQTT Broker fails to enforce ACL write permission checks when publishing Will (Last Will and Testament) messages on behalf of disconnected clients. All normal PUBLISH paths (receivedPublishQos0, receivedPublishQos1, receivedPublishQos2) correctly invoke authorizator.canWrite() before publishing, but the Will message publishing path (fireWill() → publishWill() → publish2Subscribers()) completely bypasses this authorization check.

This allows an unauthenticated attacker (when allowanonymous=true, which is the default) to inject arbitrary messages into any ACL-protected topic by setting a restricted topic as the Will Topic in the CONNECT packet and then disconnecting abruptly via TCP RST.

Other major MQTT Broker implementations (Mosquitto, EMQX, HiveMQ) correctly enforce ACL checks on Will messages, confirming this is a bug, not a design choice.

Details

In the MQTT protocol, a client can declare a "Will" topic and message in the CONNECT packet. When the client disconnects abnormally (without sending a DISCONNECT packet), the Broker publishes the Will message on behalf of the client. Although the Will message content (topic and payload) is entirely controlled by the connecting client — making it functionally equivalent to a PUBLISH — Moquette skips the ACL check for this path.

Root Cause

File: broker/src/main/java/io/moquette/broker/PostOffice.java (v0.18.0)

Will publishing path (lines 286-328) — no canWrite() check: java public void fireWill(Session bindedSession) { final ISessionsRepository.Will will = bindedSession.getWill(); if (will.delayInterval == 0) { publishWill(will); // No canWrite() check! } else { trackWillSpecificationForFutureFire(...); } }

private void publishWill(ISessionsRepository.Will will) { // ... build message ... publish2Subscribers(WILLPUBLISKER, messageExpiryInstant, willPublishMessage); // No canWrite() check! }

Normal PUBLISH path (line 641) — has canWrite() check: java if (!authorizator.canWrite(topic, username, clientID)) { LOG.error("client is not authorized to publish on topic: {}", topic); return; }

Additionally, SessionRegistry.createNewWill() (line 408-428) stores the Will topic from the CONNECT packet without any canWrite() pre-check. The fireWill()/publishWill() method is the only publishing path that does not invoke authorizator.canWrite(), creating a complete authorization bypass.

Prerequisites

| Condition | Who controls | Default? | Notes | |-----------|-------------|----------|-------| | Attacker can establish MQTT connection to Broker | Environment | Yes | allowanonymous defaults to true | | Broker has ACL restricting topic write access | Application | No | Only deployments with ACL configured have "bypass" significance, but this is a normal security deployment | | Client disconnects abnormally (TCP RST, not DISCONNECT) | Attacker | Yes | Attacker simply closes the TCP connection |

PoC

Verified against Moquette Broker v0.18.0 (latest release as of 2024-12-27). All scripts are included in the attached GitHubAdvisoryPOC.zip. GitHubAdvisoryPOC.zip Environment Setup

Step 1: Download Moquette Broker v0.18.0

Download the official release bundle from GitHub and extract:

bash curl -L -o /tmp/moquette-0.18-bundle.tar.gz "https://github.com/moquette-io/moquette/releases/download/v0.18.0/distribution-0.18-bundle.tar.gz" mkdir -p /tmp/moquette-0.18 tar xzf /tmp/moquette-0.18-bundle.tar.gz -C /tmp/moquette-0.18

Step 2: Configure ACL rules

Replace /tmp/moquette-0.18/config/acl.conf with the provided acl.conf (from POC zip), which contains:

conf acl.conf - restrict write access to restricted/topic topic write allowed/topic topic read restricted/topic

Note: Must use topic rules (not pattern rules). Moquette's AuthorizationsCollector.canDoOperation() skips pattern rules when username is null (anonymous users), because isNotEmpty(null) returns false.

Edit /tmp/moquette-0.18/config/moquette.conf to ensure ACL is enabled. Use the provided moquette.conf (from POC zip) as reference:

conf moquette.conf port 1883 host 0.0.0.0 allowanonymous true aclfile config/acl.conf

Step 3: Download dependency and compile POC scripts

Download commons-collections-3.2.1.jar (required by CC6 deserialization chain) and compile the POC Java sources (all from POC zip):

bash Download commons-collections (required for CC6 RCE POC only) Place commons-collections-3.2.1.jar in /tmp/

Compile POC scripts cd /tmp javac -cp /tmp/commons-collections-3.2.1.jar CC6PayloadGen.java # CC6 deserialization payload generator javac -cp /tmp/commons-collections-3.2.1.jar AttackerCC6v018.java # Attacker-side full POC (Will bypass + CC6 RCE) javac MqttDeviceServicev018.java # Victim-side IoT subscriber service

Scripts overview:

| Script | Language | Purpose | |--------|----------|---------| | pocwillbypass.py | Python | Lightweight Will ACL bypass verification (no Java/deserialization dependency) | | AttackerCC6v018.java | Java | Full attacker POC: generates CC6 payload, verifies ACL blocks direct PUBLISH, bypasses ACL via Will, verifies victim-side RCE | | CC6PayloadGen.java | Java | CC6 deserialization payload generator (dependency of AttackerCC6v018) | | MqttDeviceServicev018.java | Java | Victim-side IoT device subscriber — subscribes to restricted/topic, deserializes received messages via ObjectInputStream.readObject() | | MoquetteWillAclBypassPoc.java | Java | Standalone pure-Java POC for v0.15 (no external dependencies, verifies Will ACL bypass only) | | acl.conf | Config | ACL rules — restricted/topic read-only, no write | | moquette.conf | Config | Broker configuration — enables ACL, allows anonymous |

Reproduction — Will ACL Bypass Only (Python, no dependencies)

This verifies the core vulnerability: Will message bypasses ACL. Uses pocwillbypass.py.

Terminal 1 — Start the Broker (using Moquette's built-in main class io.moquette.broker.Server):

bash cd /tmp/moquette-0.18 && java -cp 'lib/:lib' io.moquette.broker.Server

Wait for "Server started" log.

Terminal 2 — Run POC:

bash python3 pocwillbypass.py

This script automatically performs: 1. Subscriber connects and subscribes to restricted/topic 2. Verifies direct PUBLISH to restricted/topic is blocked by ACL 3. Attacker connects with Will Topic=restricted/topic, then RST-disconnects 4. Checks if subscriber received the Will message on the restricted topic

Expected output: [Step 1] Direct PUBLISH to restricted/topic (should be blocked) [+] No message - ACL blocking direct PUBLISH (expected)

[Step 2] Will ACL Bypass on v0.18.0 SUBACK: 9003000100 Attacker connected, Will set to 'restricted/topic' RST disconnecting attacker... [!!!] WILL MESSAGE RECEIVED on restricted/topic! [!!!] VULNERABILITY CONFIRMED on Moquette v0.18.0!

Reproduction — Full RCE Chain (Will Bypass + CC6 Deserialization)

This demonstrates the real-world impact: Will bypass + Java deserialization = Remote Code Execution. Uses AttackerCC6v018.java, CC6PayloadGen.java, and MqttDeviceServicev018.java.

Terminal 1 — Start the Broker (using Moquette's built-in main class io.moquette.broker.Server):

bash cd /tmp/moquette-0.18 && java -cp 'lib/:lib' io.moquette.broker.Server

Wait for "Server started" log.

Terminal 2 — Start victim subscriber (MqttDeviceServicev018.java):

bash cd /tmp && java -cp .:/tmp/commons-collections-3.2.1.jar MqttDeviceServicev018 localhost 1883

This simulates an IoT device that subscribes to restricted/topic and deserializes received messages via ObjectInputStream.readObject(). Wait for:

[等待中] 等待管理平台下发指令...

Terminal 3 — Run attacker POC (AttackerCC6v018.java):

bash cd /tmp && java -cp .:/tmp/commons-collections-3.2.1.jar AttackerCC6v018 localhost 1883

This script automatically performs: 1. Generate CC6 payload — uses CC6PayloadGen.java to create a Commons Collections CC6 deserialization chain that executes touch /tmp/pwnedbywillbypass<timestamp> 2. Verify direct PUBLISH is blocked — attempts PUBLISH to restricted/topic, confirms ACL blocks it 3. Bypass ACL via Will — CONNECT with Will Topic=restricted/topic, Will Message=CC6 serialized payload, then RST disconnect 4. Verify victim-side RCE — checks if /tmp/pwnedbywillbypass<timestamp> file was created on the victim

Key verification point: Java CC6 chain triggers exec once during HashMap.put() when constructing the payload (a known CC6 artifact). The POC deletes this file before the Will bypass step, then verifies the file is re-created by the victim's readObject(), confirming the RCE is on the victim side, not a POC construction side-effect.

Expected attacker output (Terminal 3): === 攻击者 (CC6原生反序列化链) - Moquette v0.18.0 === [1] 生成CC6反序列化payload... payload长度: 1189 字节 [2] 直接PUBLISH到restricted topic (应被ACL拦截)... 已发送 [3] 通过Will消息绕过ACL... 已连接,Will Topic=restricted/topic Will Payload=CC6序列化数据(1189字节) RST断开连接... 已断开,Will消息绕过ACL投递成功 [4] 验证受害者端RCE: -rw-r--r-- 1 fire fire 0 ... /tmp/pwnedbywillbypassXXXXXXXXXXXXX RCE成功! Will消息绕过ACL投递CC6 payload,受害者readObject()触发命令执行!

Expected victim output (Terminal 2): [收到消息] MQTT消息到达,长度=1189字节 [反序列化] 正在执行 ObjectInputStream.readObject() ... [反序列化] 完成,对象类型: java.util.HashMap

Impact

- Authorization Bypass: Attacker can inject arbitrary messages into any ACL-restricted topic, completely undermining the Broker's access control - Remote Code Execution: When subscribers deserialize MQTT message payloads (e.g., using Java ObjectInputStream.readObject()), attacker can inject deserialization gadgets (e.g., Commons Collections CC6 chain) to achieve RCE - Affected scope: All IoT/messaging middleware scenarios using Moquette as MQTT Broker with ACL enabled

| Metric | Value | Rationale | |--------|-------|-----------| | Attack Vector | Network | MQTT Broker listens on TCP port, network-reachable | | Attack Complexity | Low | Standard MQTT CONNECT + TCP RST, no special conditions needed | | Privileges Required | None | allowanonymous defaults to true | | User Interaction | None | Fully automated attack | | Scope | Unchanged | Impact limited to Broker's security domain | | Confidentiality | None | No data disclosure | | Integrity | High | ACL write protection completely bypassed | | Availability | None | No service disruption | GitHubAdvisoryPOC.zip

Other sources

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.

MITRE

Affected Software

2 affected componentsFixes available
Moquette io.moquette:moquette-broker<0.18.1
maven/io.moquette:moquette-broker<0.18.1
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 to a fixed release to a version that resolves this vulnerability.

    Fixed in 0.18.1
  3. Configuration

    Edit `/tmp/moquette-0.18/config/moquette.conf` and disable anonymous access (`allow_anonymous` should not be enabled). The material states the vulnerability is exploitable when `allow_anonymous=true` (default).

    Moquette MQTT Broker allow_anonymous = true
  4. Configuration

    Replace `/tmp/moquette-0.18/config/acl.conf` with the provided `acl.conf` from `GitHub_Advisory_POC.zip` (contains rules such as `restricted/topic` read-only and no write), to ensure ACLs restrict writes to sensitive topics.

    Moquette MQTT Broker acl_file config/acl.conf = acl.conf
  5. Compensating control

    Mitigate exposure by restricting network access to the MQTT broker TCP listener (port 1883 in the PoC) so unauthenticated/anonymous clients cannot reach it.

  6. Operational

    If exploitation is suspected, remove/clean any files that could have been created via the demonstrated CC6 deserialization RCE (e.g., `/tmp/pwned_by_will_bypass_<timestamp>` on victims) and re-assess affected IoT subscriber hosts.

Event History

Sep 18, 2026
CVE Published
via MITRE·05:40 PM
Data Sourced
via MITRE·05:40 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·05:58 PM
Data Sourced
via GitHub·05:58 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to this issue?

Moquette-broker deployments earlier than 0.18.1 are exposed when anonymous access is enabled and topic ACLs restrict client writes. The issue specifically affects Last Will publication handling rather than normal PUBLISH authorization.

2

What does an attacker need to do to exploit it?

A remote client must connect with an ACL-protected Last Will Topic and then disconnect abnormally. The broker can then publish the attacker-controlled Last Will message to that protected topic without the normal write-authorization check.

3

How can I determine whether exploitation may have occurred?

Review broker activity for abnormal client disconnects followed by Last Will messages published to topics that the disconnecting client was not authorized to write. Focus on deployments with anonymous access enabled and ACL-protected topics.

4

What should be done if upgrading is not immediately possible?

Disable anonymous access to prevent the described unauthenticated attack path. Also restrict client access and monitor or limit use of Last Will Topics, particularly for ACL-protected topics.

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