Eclipse Vert.x MQTT Client Memory Exhaustion via QoS 2 Handshake
Unbounded memory growth in Vert.x MQTT clients occurs when brokers withhold PUBREL packets, allowing attackers to consume all available system memory.
Key points
- Eclipse Vert.x versions through 5.2.0 contain a flaw allowing unbounded memory growth via QoS 2 messages.
- The internal map storing inbound messages lacks a size limit, ignoring maxInflightQueue settings for incoming data.
- Malicious brokers can exploit this by sending distinct PUBLISH messages and withholding required response packets.
The Eclipse Vert.x MQTT client component contains a memory management flaw that allows an attacker to exhaust system resources. According to the National Vulnerability Database, the issue affects the vertx-mqtt module by storing inbound QoS 2 PUBLISH messages indefinitely. This behavior creates a denial-of-service condition through unbounded memory consumption in the affected application processes.
Root cause
The vulnerability stems from how the MqttClient handles QoS 2 handshake completion. The client stores every inbound QoS 2 PUBLISH message in an internal map called qos2inbound while waiting for the corresponding PUBREL packet. This map has no enforced size limit. The existing maxInflightQueue configuration only restricts outbound publish operations, leaving inbound message retention unconstrained and vulnerable to accumulation.
Attack path
An attacker controlling or compromising an MQTT broker can exploit this logic gap. By sending QoS 2 PUBLISH messages with unique packet identifiers and refusing to send the required PUBREL responses, the attacker forces the client to retain each message. Each incomplete handshake keeps the full topic, payload, and metadata in memory, leading to rapid resource exhaustion and potential application termination.
Affected versions
- Eclipse Vert.x 4.0.0 through 4.5.34
- Eclipse Vert.x 5.0.0 through 5.0.12
- Eclipse Vert.x 5.1.0 through 5.1.9
- Eclipse Vert.x 5.2.0
Mitigation
- Upgrade to a patched version of Eclipse Vert.x once the vendor provides an update.
- Implement strict memory limits on processes running the MQTT client to contain impact.
- Monitor inbound MQTT traffic for unusual volumes of QoS 2 messages from single sources.
- Validate broker integrity and ensure only trusted brokers can send QoS 2 PUBLISH messages.
Detection notes
Teams usually detect this activity by monitoring for sustained memory growth in MQTT-consuming applications. Check whether the process heap usage increases linearly without corresponding application load. Look for alerts indicating out-of-memory errors or process restarts. Examine logs for high volumes of QoS 2 inbound messages that lack subsequent completion records. Containment often involves restarting the affected service and isolating the suspicious broker to prevent further resource exhaustion.
What to do and how to stay safe: Eclipse Vert.x
- Audit your inventory for applications using the io.vertx:vertx-mqtt component.
- Verify the specific version of Eclipse Vert.x in your deployment against the affected ranges.
- Monitor system memory usage for sudden spikes in services connecting to external MQTT brokers.
- Prepare to isolate network connections to untrusted brokers once the vendor provides an update.
Step-by-step guide: Unpatched Software Myths: Why Common Beliefs Fail to Protect You
General security guidance from the BlueTeam Insider newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Is there a confirmed patch for CVE-2026-102464?
No fix has been confirmed yet in the provided source material.
Does the maxInflightQueue setting protect against this vulnerability?
No, the maxInflightQueue option is enforced only on the outbound publish path and does not constrain inbound message retention.
Which specific component is affected by this flaw?
The impacted component is io.vertx:vertx-mqtt within the Eclipse Vert.x framework.
