Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect anonymously to broker
-
DeliverySet ACL-restricted topic as Will in CONNECT
-
ExploitAbruptly disconnect via TCP RST
-
ExecutionpublishWill bypasses canWrite check
-
ImpactForged message injected to restricted-topic subscribers
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the broker to run with allow_anonymous=true (Moquette's default) so an unauthenticated client can connect, AND the operator to have configured topic write ACLs (an IAuthorizatorPolicy denying canWrite on some topics) - without a restrictive ACL there is no protection to bypass and no security impact. The attacker must set the ACL-protected topic as the Last Will Topic in the CONNECT packet and then trigger abnormal disconnection (e.g. TCP RST) rather than a clean DISCONNECT so the broker fires the Will. Affected versions are moquette-io:moquette < 0.18.1; limiting factors are the ACL-dependent configuration and that each event injects only a single attacker-controlled message (though repeatable by reconnecting). |
| Impact | CVSS 3.1 base 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) reflects a network-reachable, unauthenticated, low-complexity integrity-only flaw with no confidentiality or availability impact - consistent with CWE-862 missing authorization on the Last Will publish path. All exploitation signals point to a real but conditional bug rather than a widely-weaponized threat: no EPSS score is provided, KEV=NO (not in CISA KEV), and there is no public exploit code - only a vendor GHSA advisory with root-cause analysis and a regression test. The SSVC picture is: exploitation=none observed, automatable=yes (scriptable CONNECT-with-Will then TCP RST), technical impact=partial (single-topic integrity injection). The most important nuance the raw 7.5 hides is the gating: impact only materializes when the operator has configured write ACLs AND left allow_anonymous=true (the default); on brokers with no ACL policy there is nothing to bypass. Also note the I:H rating is generous - each abnormal disconnect injects one attacker-controlled Will message, so integrity impact per event is bounded (though repeatable via reconnection). Net: a legitimate authorization-bypass worth patching for ACL-dependent deployments, but real-world priority is tempered by niche product footprint, no active exploitation, and dependence on a specific ACL+anonymous configuration. |
| Exploit ScenarioDerived | On a Moquette broker with allow_anonymous=true (default) and a write ACL protecting a sensitive topic (e.g. commands/actuator), an unauthenticated attacker opens a CONNECT specifying that restricted topic as the Last Will Topic with an attacker-chosen payload, then abruptly drops the TCP connection with an RST. The broker fires the Will through publishWill()→publish2Subscribers() without calling authorizator.canWrite(), delivering the forged message to all subscribers of the ACL-protected topic. No public exploit code is published, but the GHSA advisory documents the exact code path and ships a regression test demonstrating the behavior. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Moquette MQTT brokers running versions prior to 0.18.1 fail to enforce topic write ACLs on Last Will and Testament messages, letting a remote, unauthenticated client (CVSS vector contains PR:N) publish attacker-controlled payloads into ACL-protected topics it is not permitted to write to. The attacker sets a restricted topic as the Will Topic in the CONNECT packet and then drops the connection abnormally (for example with a TCP RST) so the broker fires the Will through PostOffice.publishWill() → publish2Subscribers() without ever calling authorizator.canWrite(), the check that guards normal QoS 0/1/2 PUBLISH paths. The published CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N); our independent assessment concurs on network reachability, no privileges and no user interaction, with integrity-only impact, though it rates the per-event integrity effect as low because each bypass delivers only a single message (repeatable by reconnecting). No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in 0.18.1.
RemediationAI
Apply the vendor-released patch by upgrading io.moquette:moquette-broker to version 0.18.1 or later (fixed release: https://github.com/moquette-io/moquette/releases/tag/v0.18.1); the fix is implemented in commit e23df019f6a11e22c7d2047d4f86d07095466c97 with supporting changes in commit f5a323fe782d1505c0097498cb22eb6ec6c96973, and full details are in advisory GHSA-9jjc-fw8x-fmwx. If immediate upgrade is not possible, the most effective compensating control is to disable anonymous access (set allow_anonymous=false and require authenticated clients), which removes the unauthenticated entry point this bypass depends on - the trade-off is that any legitimate anonymous clients or devices will stop connecting until credentials are provisioned. A second option is to make ACLs permissive rather than restrictive if they are not actually needed; since the bypass is only exploitable when canWrite denies a topic, removing unused write restrictions eliminates the impact, but it also removes whatever protection those ACLs provided against ordinary unauthorized PUBLISH. Because the flaw lives in the Will dispatch path, client-side or per-topic client changes cannot fix it; a fronting TLS-terminating proxy could theoretically parse CONNECT packets and reject Will topics a client is not authorized to write, but this requires MQTT-aware inspection, adds latency and operational complexity, and is fragile for embedded brokers that do not sit behind a proxy. Until patched, monitor broker logs for the unauthorized-publish error messages and for anomalous Will publication into restricted topics, and treat any restart, network drop or TCP RST that triggers unexpected messages on protected topics as a possible exploitation attempt. No vendor patch alternative or workaround beyond these compensating controls is documented in the advisory.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Moquette is a lightweight, embeddable Java MQTT broker (Maven coordinates io.moquette:moquette-broker; CPE cpe:2.3:a:moquette-io:moquette, all versions before 0.18.1). MQTT lets a connecting client declare a Last Will and Testament in the CONNECT packet - a topic plus payload the broker must publish on the client's behalf if the client disconnects abnormally without sending a DISCONNECT packet. Because the Will topic and payload are entirely client-controlled and are disseminated to subscribers exactly like a normal PUBLISH, they are functionally equivalent to a PUBLISH and must be subjected to the same authorization. In Moquette 0.18.0 and earlier, the Will path (SessionRegistry.createNewWill() stores the topic unchecked, then fireWill() → publishWill() → publish2Subscribers()) never invokes authorizator.canWrite(), whereas the normal paths (receivedPublishQos0/1/2 in broker/src/main/java/io/moquette/broker/PostOffice.java) do. This is the classic CWE-862 Missing Authorization root cause: an alternate code path reaches the same privileged operation without passing through the authorization gate. Comparable brokers (Mosquitto, EMQX, HiveMQ) do enforce ACL checks on Will messages, confirming this is a defect rather than an intentional design choice. The bypass is only meaningful when the broker runs with allow_anonymous=true (Moquette's default) and the operator has configured an IAuthorizatorPolicy that denies canWrite on at least one topic - without such an ACL there is nothing to bypass. The official fix (commit e23df019f6a11e22c7d2047d4f86d07095466c97, accompanied by a regression test WillUnauthorizedPublishTest) adds an authorizator.canWrite() check inside publishWill() before dispatch, and a second commit f5a323fe782d1505c0097498cb22eb6ec6c96973 supports the change.
Know when Moquette gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Network, anonymous (PR:N via default allow_anonymous), no UI; integrity-only injection of a single Will message per connection into a restricted topic argues I:L rather than I:H; no confidentiality/availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Articles & Coverage 1
Technical POC Analysis
CWE-862 (Missing Authorization) in broker/src/main/java/io/moquette/broker/PostOffice.java in io.moquette:moquette-broker (v0.18.0).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Moquette MQTT brokers running versions below 0.18.1 let an unauthenticated remote party place messages into topic namespaces that access controls are meant to protect, by declaring a restricted topic as a client's Last Will and then breaking the connection abnormally. Any organization relying on Moquette as the messaging backbone for IoT, OT, or device-management estates should treat this as a control-integrity risk: untrusted parties - including anyone able to reach the broker port - could deliver forged command or status payloads that downstream subscribers accept as legitimate, with no credentials required. There is no vendor-released patch identified at time of analysis, and no public exploit code has been identified, though the bypass is trivially repeatable by reconnecting.
No vendor-released patch identified at time of analysis. Interim mitigations: disable or restrict Last Will message support where not operationally required; enforce client authentication (credentials or mTLS) at the broker so unauthenticated CONNECT packets are rejected; restrict MQTT listener exposure to trusted networks through firewall rules and segmentation; block or quarantine CONNECT packets whose Will Topic falls outside the connecting client's authorized write scope; alert on abnormal disconnects (for example TCP RST) immediately followed by publishes to ACL-protected topics; and validate or sign payloads in downstream consumers of safety-critical command topics until brokers are upgraded.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Moquette MQTT brokers prior to 0.18.1 can start up with authentication and authorization silently disabled whenever a co
Durable MQTT sessions in Moquette 0.18.0 and earlier can corrupt each other's persisted queues when a client connects wi
Remote, pre-authentication denial of service in the Moquette MQTT broker (moquette-io moquette-broker) through 0.18.0 al
Denial of service in the Moquette lightweight Java MQTT broker prior to 0.18.1: a single remote, unauthenticated MQTT cl
Unbounded per-session message queuing in Moquette MQTT Broker before 0.18.1 permits remote unauthenticated clients to ex
Remote unauthenticated clients can crash a Moquette MQTT broker running 0.18.0 or earlier by publishing or subscribing w
Unauthorized message injection in the Moquette lightweight Java MQTT broker affects all releases prior to 0.18.1: PostOf
EUVD-2026-83269
GHSA-9jjc-fw8x-fmwx
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB