CVE-2026-95847 is a high severity (CVSS 7.5) flaw in the Moquette Java MQTT broker before 0.18.1. Queue names built from client IDs can collide, so two durable sessions share one storage map and can corrupt it or see each other's queued content. 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 with 0.18.1 and 0.19.0 patched. The weakness is CWE-99, improper control of resource identifiers.
Per the record, the persistent queue built on the H2 store names a session's message map by joining a prefix and the client ID, and its metadata map by adding a suffix. A durable session whose client ID ends in the suffix can make its message map collide with another client's metadata map. Both sessions then read and write the same map with incompatible value types.
The record lists the effects: corrupted queue head and tail data, message loss, misdelivery, failed queue reloads and exposure of queued content across sessions. The vector is network, low complexity, no privileges, with high integrity impact. This applies to deployments that use durable sessions with the persistent H2 queue.
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 check whether you use durable sessions with persistent storage. If your broker runs with in memory queues only, the storage collision does not arise, though you should still upgrade for the other fixes.
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 client ID rules. If you issue client IDs yourself, make sure none ends with the suffix the record mentions.
- After the upgrade, check persistent queues for signs of corruption such as sessions that fail to reload, and clear them if needed.
- 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 bug is in how names are made. When an identifier is built by joining pieces and one piece comes from the client, the client can choose a value that makes two different things end up with the same name. CWE-99 covers this family. The fix is to build names so that no client chosen string can look like the structure around it.
The effect goes beyond availability. Messages can be lost, delivered to the wrong party or shown to someone else. 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
Does this affect brokers with in memory sessions only?
The record describes the H2 persistent queue and durable sessions. Check how your broker stores sessions.
What can go wrong?
Message loss, misdelivery, failed queue reloads and exposure of queued content across sessions, according to the record.
Sources
Last reviewed: 18 October 2026.
