CVE-2026-95846 is a high severity (CVSS 7.5) missing authorization flaw in the Moquette Java MQTT broker before 0.18.1. The Last Will message is published without the write permission checks used for normal publishes, so a client can inject messages into restricted topics. Upgrade to 0.18.1 or 0.19.0.
What's affected
The record says Moquette before 0.18.1 is affected, and the advisory lists up to 0.18.0 as affected and 0.18.1 and 0.19.0 as patched. The weakness is CWE-862, missing authorization.
Per the record, the routine that publishes a client's Last Will message does not apply the write permission check or the reserved topic check that a normal publish goes through. A client can set a Will for a topic that it is not allowed to write, and when it disconnects unexpectedly the broker publishes the message anyway.
The result is unauthorized message injection into restricted topics. The vector is network, low complexity, no privileges, with high integrity impact and no confidentiality or availability impact.
How to check if you're exposed
Moquette is an embedded Java MQTT broker, so it often hides inside an application rather than running as its own service. Search your build for it.
mvn dependency:tree | grep -i moquette
gradle dependencies | grep -i moquette
Look for the moquette-broker artifact and its version. Anything at or below 0.18.0 is in scope per the advisory. Also check container images and fat jars, where the library is bundled inside another file.
Then ask who can connect. The advisory notes that the broker is reachable by untrusted MQTT clients and, by default, accepts anonymous ones.
Then review your authorization setup. If you rely on topic permissions to protect command or control topics, treat those protections as bypassable on affected versions through the Will path.
What to do now
- Upgrade Moquette to 0.18.1 or later. The advisory lists 0.18.1 and 0.19.0 as patched.
- Rebuild and redeploy every application that embeds the broker, since a library update does nothing until the application is rebuilt.
- Turn off anonymous access if you do not need it and require authentication for clients.
- Put the broker port behind a firewall or private network where clients are known.
- Review topics that carry commands, configuration or alerts, and check subscribers do not trust a message only because it arrived on that topic.
- Where your subscribers can verify message origin, for example with a signature, add that check.
- Paste your lockfile or manifest into the free in-browser dependency scan to see whether the affected package is in your tree, then use reachability analysis to separate code paths you call from ones you never touch.
Why it matters
Access control has to cover every way a message can enter the system. A normal publish was checked, but the Will, a message the broker sends on the client's behalf, took a different code path that was not. CWE-862 describes that gap. The broker did the right thing in the main path and forgot a side door.
In a system where messages trigger actions, such as switching a device or raising an alarm, injection into a restricted topic is a real integrity risk. The advisory that covers these fixes also describes other problems in the broker, including a pattern based authorization bypass, so upgrading is the safe course rather than picking individual fixes. The record does not mark exploitation, and the CVE is not in CISA's catalog.
Quick check
What is a Last Will message?
In MQTT, a client can register a message that the broker sends if the client disconnects unexpectedly. The flaw is that the broker did not check write permission for it.
What does the attacker gain?
The ability to publish to topics they are not permitted to write, per the record.
Sources
Last reviewed: 18 October 2026.
