CVE-2026-95845 is a high severity (CVSS 7.5) resource exhaustion flaw in the Moquette Java MQTT broker before 0.18.1. Pending per session message queues have no maximum length, so a fast publisher aimed at a slow subscriber can fill memory or storage. The fixed versions are 0.18.1 and 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 with 0.18.1 and 0.19.0 patched. The weakness is CWE-770, allocation of resources without limits or throttling.
Per the record, when a subscriber's in flight window is full, queued messages can build up without bound in memory or in persistent storage. Remote clients can use that to exhaust the broker's resources and cause denial of service.
The vector is network, low complexity, no privileges, high availability impact. Note that this resembles ordinary overload, so it can also happen without an attacker, for example when a consumer stalls and a producer keeps sending.
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.
Also look at your broker's memory and disk graphs, and at queue sizes for sessions whose subscribers are slow or offline. Steady growth with no ceiling is the sign of this behavior.
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.
- Set alerts on broker memory, disk and queue depth so growth shows up before it becomes an outage.
- Give the broker a memory limit and restart policy at the container or service level.
- 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
Queues make systems forgiving, because a slow consumer does not lose messages. A queue with no limit makes them fragile, because the producer and the consumer decide how large the problem gets. CWE-770 is the general form: a resource handed out with no cap. The cure is a limit and a policy for what happens when it is reached, such as dropping the oldest message or refusing new ones.
For IoT and telemetry brokers, this matters as much for accidents as for attackers. 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 fills up?
Memory or persistent storage, according to the record, depending on how the broker is set up.
Can this happen without an attack?
A fast producer and a stalled consumer can produce the same pattern. The fix adds the limit that was missing.
Sources
Last reviewed: 18 October 2026.
