Eclipse Vert.x MQTT Client Vulnerability Allows Unbounded Memory Growth

Eclipse Vert.x MQTT clients contain a memory management flaw that allows remote brokers to exhaust system resources. The issue, tracked as CVE-2026-102464, carries a CVSS score of 8.2, which is rated as high severity.

What happened

The Eclipse Foundation’s Vert.x project maintains an MQTT client library used by many Java-based applications. According to the National Vulnerability Database record for CVE-2026-102464, the flaw exists in how the MqttClient handles QoS 2 PUBLISH messages. When the client receives these messages from a broker, it stores them in an internal map called qos2inbound while waiting for the corresponding PUBREL packet to complete the handshake process.

The internal map has no defined size limit for these stored messages. The maxInflightQueue configuration option, which might otherwise constrain message handling, is enforced only on the outbound publish path. It does not restrict the retention of inbound messages. This architectural gap means the client continues to hold data indefinitely if the handshake is not completed.

A malicious or compromised MQTT broker can exploit this behavior by sending QoS 2 PUBLISH messages with distinct packet identifiers. The broker then withholds the necessary PUBREL responses. Each incomplete handshake forces the Vert.x process to retain the full publish message, including the topic, payload, and metadata. This leads to unbounded memory growth within the application process.

Why it matters

The primary risk is the degradation of the MQTT-consuming application or complete out-of-memory termination. As the internal map grows without limit, the Java process consumes increasing amounts of available memory. This can starve other processes on the same host or cause the application to crash unexpectedly.

The affected component is io.vertx:vertx-mqtt. The vulnerability impacts Eclipse Vert.x versions 4.0.0 up to 4.5.34. It also affects versions 5.0.0 up to 5.0.12, 5.1.0 up to 5.1.9, and version 5.2.0. Any application using these specific versions of the library is potentially vulnerable to this denial-of-service vector.

What to watch

• Monitor application logs for signs of memory pressure or frequent garbage collection cycles.
• Watch for unexpected application restarts or out-of-memory errors in services using Vert.x MQTT.
• Check network traffic for unusual patterns of QoS 2 messages from trusted brokers.
• Verify that your inventory includes all instances of the affected io.vertx:vertx-mqtt versions.

Who needs to act first

Teams should immediately identify which production systems rely on the affected Vert.x MQTT client versions. Prioritize updating or isolating systems that connect to external or untrusted MQTT brokers, as these face the highest exposure risk. If a patch is not yet available, consider implementing network-level controls to restrict which brokers your clients can connect to. Test any temporary mitigations in a non-production environment first to ensure they do not disrupt legitimate message flows. Back up configuration files before making changes to network rules or application settings.

Background: CVSS score

The CVSS score explains vulnerability severity using a 0.0 to 10.0 scale. It measures attack vector, complexity, privileges required, and impact on confidentiality, integrity, and availability. You use this metric to prioritize patches, though you must adjust it for your specific environment to avoid wasting time on irrelevant threats.

Read the full guide: CVSS Score Explained: How to Read Risk Metrics and Prioritize Fixes

What to do and how to stay safe: Eclipse Vert.x

• Audit your application dependencies to confirm if you are using io.vertx:vertx-mqtt versions 4.0.0 through 4.5.34 or the specified 5.x ranges.
• Monitor memory usage of processes running the affected MQTT clients for sudden or steady increases.
• Restrict MQTT client connections to trusted, internal brokers only if possible to reduce exposure to malicious actors.
• Once the vendor provides an update, test the patched version in a staging environment before deploying to production.

Step-by-step guide: Virtual Patching Myths: What It Actually Fixes and Breaks

General security guidance from the Patch Gazette newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which specific versions of Eclipse Vert.x are vulnerable to CVE-2026-102464?

Versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 are affected.

Is there a patch available for this MQTT client vulnerability?

No fix has been confirmed yet for the affected versions of the io.vertx:vertx-mqtt component.

How does a malicious broker exploit this flaw?

By sending QoS 2 PUBLISH messages with distinct IDs and withholding PUBREL responses, causing unbounded memory growth.