CVE-2026-95843 is a high severity (CVSS 7.5) input validation flaw in the Moquette Java MQTT broker before 0.18.1. A shared subscription filter that lacks its topic part throws an exception that ends command handling on a shared loop and denies service to other clients. Upgrade to 0.18.1 or 0.19.0.
What's affected
The record says Moquette before 0.18.1 is affected, and the GitHub advisory lists up to 0.18.0 as affected, with 0.18.1 and 0.19.0 patched. The weakness is CWE-20, improper input validation.
Per the record, the broker's subscribe path pulls the share name out of a shared subscription filter before it validates the whole structure of the filter. MQTT shared subscriptions use a filter that carries a group name and then a topic filter. A filter that stops after the group name causes a string index exception while the share name is being worked out.
The exception ends command handling on the shared session event loop, and so other client sessions on that loop are denied service. The vector is network, low complexity, no privileges, high 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.
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.
- Where you front the broker with a gateway, consider rejecting shared subscription filters you do not use.
- 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
The order of checks is the lesson. The code used part of the filter before it confirmed that the filter was well formed. CWE-20 usually comes down to that: validate first, then use. A malformed value that should have produced a polite error produced an exception, and in a design where loops are shared, one exception hurts many.
This issue and its siblings in the same advisory show why a small broker needs defensive handling at every protocol entry point. 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.
Quick check
What input triggers it?
A shared subscription filter that has the group name but no topic filter part, according to the record.
Is the effect limited to the sender?
No. It can deny service to other client sessions assigned to the same event loop.
Sources
Last reviewed: 18 October 2026.
