CVE-2026-95845: Moquette MQTT Broker DOS Vulnerability

CVE-2026-95845 Overview

CVE-2026-95845 is a denial-of-service vulnerability in Moquette, a lightweight Java MQTT broker. Versions prior to 0.18.1 do not enforce a maximum length on pending per-session message queues. When a fast publisher sends messages to a slow subscriber whose in-flight window is full, queued messages accumulate without bound in memory or persistent storage. Remote clients can trigger this condition to exhaust broker resources and render the service unavailable. The issue is tracked under [CWE-770] (Allocation of Resources Without Limits or Throttling) and is fixed in Moquette 0.18.1.

Critical Impact
Unauthenticated remote clients can exhaust broker memory or persistent storage by exploiting unbounded per-session queues, causing denial of service.

Affected Products

Moquette MQTT Broker versions prior to 0.18.1
Java applications embedding the Moquette broker library
MQTT deployments relying on Moquette for IoT message routing

Discovery Timeline

2026-09-23 - CVE-2026-95845 published to NVD
2026-09-23 - Last updated in NVD database
Fix released - Moquette v0.18.1 published on GitHub

Technical Details for CVE-2026-95845

Vulnerability Analysis

Moquette manages per-session queues for messages awaiting delivery to subscribed clients. MQTT quality-of-service semantics require the broker to retain in-flight messages until the subscriber acknowledges them. In vulnerable releases, these queues have no upper size limit. A subscriber that stops acknowledging messages, or that has a full in-flight window, causes queued messages to pile up in broker memory or the H2 persistent store. A remote publisher can accelerate this growth by publishing rapidly to a topic the slow subscriber follows.

The result is unbounded resource consumption. The broker eventually exhausts heap memory, disk space, or both, leading to service degradation and denial of service for all connected clients.

Root Cause

The root cause is the absence of a bounded-queue policy in the session-management layer. Session queues grew based only on publisher throughput and subscriber acknowledgement rate, with no back-pressure or drop policy. This is a classic [CWE-770] resource-allocation flaw. The patch introduces a compile-time constant MAX_ELEMENT_IN_QUEUE in BrokerConstants.java that caps queue size.

Attack Vector

Exploitation requires only network access to the MQTT broker. An attacker connects one client that subscribes to a topic and stops acknowledging messages, then uses a second client to publish a high volume of messages to that topic. Because the specification allows any authenticated or anonymous client to subscribe and publish, brokers configured without authentication are directly exposed. No user interaction and no privileges are required.

java

// Patch: broker/src/main/java/io/moquette/BrokerConstants.java
     public static final int DISABLED_TOPIC_ALIAS = 0;
     
     public static final int MAX_TOPIC_DEPTH = 1024;
+    public static final int MAX_ELEMENT_IN_QUEUE = 32;
+
 
     private BrokerConstants() {
     }

Source: Moquette commit 2482cad. The patch adds an explicit ceiling on per-session queue length so a slow subscriber cannot force unbounded accumulation.

Detection Methods for CVE-2026-95845

Indicators of Compromise

Sustained heap growth in the Moquette JVM process without a corresponding rise in delivered messages
Rapidly expanding H2 persistent queue files on the broker host
One or more subscriber sessions with steadily increasing pending-message counts and stalled acknowledgement rates
Broker log entries reporting OutOfMemoryError or disk-write failures

Detection Strategies

Monitor MQTT broker JMX metrics for per-session queue depth and flag sessions exceeding a static threshold
Correlate publisher message rate against subscriber acknowledgement rate to identify asymmetric flows
Track file-system growth for the Moquette data directory and alert on abnormal expansion
Inspect connection patterns for clients that subscribe with QoS 1 or QoS 2 and never send PUBACK or PUBREC

Monitoring Recommendations

Enable structured logging on the Moquette broker and ship logs to a centralized SIEM for retention and search
Instrument the host with resource-utilization telemetry covering heap, CPU, and disk consumption
Baseline normal client behavior and alert when in-flight window utilization stays saturated for extended periods

How to Mitigate CVE-2026-95845

Immediate Actions Required

Upgrade Moquette to version 0.18.1 or later, which enforces MAX_ELEMENT_IN_QUEUE = 32 on per-session queues
Restrict broker network exposure by placing the service behind a firewall or VPN and blocking untrusted sources
Enable authentication and access-control lists so anonymous clients cannot subscribe or publish
Audit existing sessions and terminate any clients showing abnormally large pending-message backlogs

Patch Information

The fix is included in Moquette v0.18.1. Details are documented in GitHub Security Advisory GHSA-5f42-97gr-vfhq and the upstream commit. The patch also adds a topic-depth guard and hardens ACL substitution against a null-username DoS.

Workarounds

Place a rate-limiting proxy or MQTT-aware gateway in front of the broker to cap per-client publish rates
Enforce short session-expiry intervals and disable persistent sessions where clients are untrusted
Provision host-level resource quotas so unbounded queue growth cannot exhaust the underlying system
Require mutual TLS authentication to prevent unauthenticated clients from establishing subscriptions

bash

# Example: upgrade Moquette dependency in Maven
mvn versions:use-dep-version -Dincludes=io.moquette:moquette-broker -DdepVersion=0.18.1 -DforceVersion=true

# Example: upgrade in Gradle build.gradle
# implementation 'io.moquette:moquette-broker:0.18.1'

# Verify running version
java -jar moquette-broker-0.18.1.jar --version