Safeguard
Vulnerability Analysis•

CVE-2026-95842: High Event Loop Crash in Moquette MQTT Broker

Moquette before 0.18.1 lets one MQTT command kill a shared event loop and stall every client on it (CVSS 7.5). Upgrade to 0.18.1 or 0.19.0 and rebuild.

Safeguard Security Team
4 min read

CVE-2026-95842 is a high severity (CVSS 7.5) denial of service in the Moquette Java MQTT broker before 0.18.1. An MQTT command that raises an uncaught exception can end an event loop shared by many client sessions and stop them all. The fixed versions are 0.18.1 and 0.19.0.

What's affected

The record says Moquette before 0.18.1 is affected. The GitHub advisory lists versions up to 0.18.0 as affected and 0.18.1 and 0.19.0 as patched. The weakness is CWE-248, uncaught exception.

The cause, per the record, is that the session event loop catches only InterruptedException, and the loop group does not restart a loop that has terminated. A command that throws any other exception ends the loop. Every client session assigned to that loop then stops processing publish, subscribe, acknowledgment and other commands. The record adds that an attacker can choose client IDs that map to each available loop, so the whole broker can be disrupted.

The vector is network, low complexity, no privileges, with 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

  1. Upgrade Moquette to 0.18.1 or later. The advisory lists 0.18.1 and 0.19.0 as patched.
  2. Rebuild and redeploy every application that embeds the broker, since a library update does nothing until the application is rebuilt.
  3. Turn off anonymous access if you do not need it and require authentication for clients.
  4. Put the broker port behind a firewall or private network where clients are known.
  5. Add an external health check that publishes and receives a test message, and restart the broker automatically if it fails, so a stalled loop does not wait for a person.
  6. 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

Event loops give a broker speed by letting one thread serve many connections. The cost is that one thread is a shared fate. If untrusted input can throw an exception that nobody catches, that thread dies and takes its clients with it. CWE-248 is the name for the missing catch.

Nothing was stolen here. The harm is availability, which in an IoT or telemetry system can mean lost readings, or control messages that never arrive. 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.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Does the attacker need credentials?

The record lists no privileges required, and the advisory says the broker accepts anonymous clients by default.

Which versions fix it?

0.18.1 and 0.19.0, according to the advisory.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.