<!--This ticket is confidential.--> <!--############################# Do not remove the lines above #############################--> # CVE Reservation Request <!--There's help in the Eclipse Foundation Project Handbook https://www.eclipse.org/projects/handbook/#vulnerability-cve Note that this issue is configured (see the quick actions at the bottom) to be created as confidential. Note that a vulnerability does not need to actually be resolved before it is reported and that these reports can be revised as needed (reopen the issue to request changes). If you do not know how to fill certain fields, mark that in the comment and we will help you. You can delete the comments (or not).--> The Eclipse Foundation is a [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE) Numbering Authority. Creating this ticket initiates **reservation** of a CVE ID for the documented vulnerability. The reserved CVE ID will be posted in a comment below, and kept **confidential** until explicit publication request. > [!note] > > To request CVE _publication_, please open a [CVE publication](https://gitlab.eclipse.org/security/cve-assignment/-/issues/new?issuable_template=CVE%20Publication%20Request&issue%5Bconfidential%5D=true) ticket. Please fill in the fields below to draft the CVE record. --- <!--Required. Specify the project's name (e.g., "Eclipse Dash") and Eclipse Foundation ID, e.g., "technology.dash".--> ## CVE record information **Project name:** Eclipse Vert.x **Project id:** rt.vertx **Versions affected:** \[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\] **Common Vulnerability Scoring System:** CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H **Summary:** 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. **Links:** https://github.com/vert-x3/vertx-mqtt/security/advisories/GHSA-46xj-5735-6qrp **Credits:** Youngjoon Kim