Eclipse Vert.x MQTT CVE-2026-102464

Requires that the Vert.x application act as an MQTT client using io.vertx:vertx-mqtt MqttClient AND process QoS 2 (exactly-once) inbound messages from a broker the attacker controls or has compromised - the malicious behavior is a broker sending QoS 2 PUBLISH packets with distinct packet IDs while withholding PUBREL. Affected versions: Vert.x [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9], and 5.2.0. LIMITING FACTORS: the attacker must occupy the broker role (not an arbitrary remote attacker), which is why CVSS rates AC:H; deployments that only connect to fully trusted, operator-controlled brokers, or that do not use QoS 2, are not realistically exposed. The maxInflightQueue option does NOT mitigate this because it constrains only the outbound publish path.

This is a genuine but bounded availability risk, not a top-tier emergency. The input CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) scores 8.2 (High) and correctly reflects a network-reachable, availability-only impact (VC:N/VI:N - no data exposure). The key tempering signal is AC:H: exploitation requires the attacker to control the MQTT broker the client connects to, which is a position of trust rather than an opportunistic internet attack. No EPSS score, no CISA KEV listing, and no public exploit were provided, so exploitation is not confirmed in any form - treat this as a latent weakness, not an actively abused one. Signals are internally consistent (DoS-only impact, broker-dependent attack), so there is no CVSS-vs-description contradiction. Note one metadata conflict to flag: the 'Information Disclosure' tag contradicts the vector, which shows C:N/I:N and A:H - this is a memory-exhaustion denial of service, NOT information disclosure. Overall priority: moderate - patch promptly in any deployment where the Vert.x application consumes QoS 2 messages from brokers it does not fully control, but it does not warrant emergency out-of-band response.

An application built on Eclipse Vert.x uses the vertx-mqtt MqttClient to subscribe to a broker that is attacker-controlled or has been compromised. The broker sends a flood of QoS 2 PUBLISH messages, each with a distinct packet identifier, and deliberately never sends the corresponding PUBREL packets. Each incomplete handshake is retained forever in the unbounded qos2inbound map, so client heap grows without limit until the application degrades or is killed by an out-of-memory error. No public exploit code was identified at time of analysis; exploitation is straightforward for any party able to act as the client's broker.