CVE-2026-102464 in Vert.x
Summary
by MITRE • 10/15/2026
In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Eclipse Vert.x MQTT (vertx-mqtt) MqttClient stores every inbound QoS 2 PUBLISH message received from the broker in an internal map (qos2inbound) while awaiting the corresponding PUBREL packet to complete the QoS 2 handshake. This map has no size limit; the maxInflightQueue option is enforced only on the outbound publish path and does not constrain inbound message retention.
A malicious or compromised MQTT broker can exploit this by sending QoS 2 PUBLISH messages with distinct packet identifiers and withholding the PUBREL responses. Each incomplete handshake causes the client to retain the full publish message (topic, payload, and metadata) indefinitely, leading to unbounded memory growth in the Vert.x process. This can degrade the MQTT-consuming application or cause out-of-memory termination.
The impacted component is io.vertx:vertx-mqtt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
Eclipse Vert.x versions ranging from 4.0.0 through 5.2.0 contain a critical resource management flaw within its MQTT client implementation, specifically in the vertx-mqtt module. The vulnerability stems from an unbounded memory allocation pattern associated with the handling of Quality of Service level 2 messages. In the MQTT protocol, QoS 2 ensures exactly-once delivery through a four-step handshake involving PUBLISH, PUBREC, PUBREL, and PUBACK packets. When the Vert.x client receives an inbound QoS 2 PUBLISH message from a broker, it stores the complete message data in an internal map designated as qos2inbound. This storage is necessary to await the corresponding PUBREL packet that signals the completion of the handshake process. However, the implementation fails to enforce any size limit on this retention structure. While the maxInflightQueue configuration option exists within the client settings, it is strictly applied only to outbound publish operations and does not constrain the volume or number of inbound messages retained in memory while awaiting acknowledgment.
This architectural oversight creates a significant denial-of-service vector against applications utilizing the affected Vert.x MQTT clients. A malicious actor who controls or compromises an MQTT broker can exploit this behavior by initiating QoS 2 PUBLISH exchanges with unique packet identifiers and subsequently withholding the required PUBREL responses. Because the client treats each incomplete handshake as a pending transaction, it continues to hold the full payload, topic metadata, and associated headers in memory indefinitely. As the attacker sends more messages without completing the acknowledgment sequence, the internal map grows without bound. This leads to unbounded memory consumption within the Java Virtual Machine hosting the Vert.x application. The operational impact is severe, potentially resulting in significant performance degradation due to garbage collection pressure or a complete out-of-memory termination of the consuming application, thereby disrupting service availability for downstream consumers relying on that data stream.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-787, Out-of-bounds Write in certain interpretations where memory exhaustion leads to system instability. In the context of the MITRE ATT&CK framework, this behavior facilitates an Impact category attack vector related to Denial of Service via resource exhaustion. The flaw highlights a common pitfall in asynchronous messaging systems where backpressure mechanisms are not symmetrically applied to both inbound and outbound data flows. Developers must recognize that configuration options for flow control often require explicit implementation on the receiving side if they do not apply by default across all message directions.
Mitigation strategies should prioritize upgrading to patched versions of Eclipse Vert.x where this memory leak has been addressed, ensuring that internal maps are bounded or that idle entries are purged after a reasonable timeout period. For environments unable to upgrade immediately, implementing an external monitoring solution is critical to detect abnormal memory growth patterns in the JVM hosting the MQTT client. Additionally, application-level defenses can be introduced by wrapping the MQTT client with a circuit breaker pattern that disconnects from brokers exhibiting suspicious behavior, such as sending excessive QoS 2 messages without completing handshakes within expected timeframes. Network segmentation and strict broker authentication policies also help reduce the attack surface by limiting which entities can establish high-volume QoS 2 connections to vulnerable clients.