Skip to main content

Moquette EUVDEUVD-2026-83269

| CVE-2026-85058 HIGH
Missing Authorization (CWE-862)
2026-09-18 GitHub_M GHSA-9jjc-fw8x-fmwx
7.5
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Connect anonymously to broker
  2. Delivery
    Set ACL-restricted topic as Will in CONNECT
  3. Exploit
    Abruptly disconnect via TCP RST
  4. Execution
    publishWill bypasses canWrite check
  5. Impact
    Forged 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

moquette < 0.18.1

Affected Packages

maven io.moquette:moquette-broker fix: 0.18.1
euvd moquette fix: 0.18.1

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

Vendor (GitHub_M) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
vuln.today AI 5.3 MEDIUM

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch available
Sep 18, 2026 - 19:03 EUVD
CVE Published
Sep 18, 2026 - 17:40 cve.org
HIGH 7.5

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

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

Why It Matters

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.

Business Impact: High
Compensating Controls

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

EPSS Score
0.3%
Top 80% exploitable
Prevalence
Low
niche open-source lightweight Java MQTT broker, limited enterprise footprint
Threat Intel
1
1 source
Exploit
POC
Public exploit code exists
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC Yes
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

58
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy