CVE-2026-102469: Maven/io.vertx/vertx-db2-client vulnerability
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 Vert.x DB2 client (vertx-db2-client) contains DRDA protocol handling code that deserializes User Defined Type (UDT) column data using a bare ObjectInputStream.readObject() call with no ObjectInputFilter or class allowlist.
This code path is triggered when a DRDA server sends a result set with a column tagged as UDT (FDOCA protocol LID 0x50). However, DB2 does not support this type of UDT. The FDOCA 0x50 type is never sent by a legitimate DB2 server.
Nevertheless, a malicious or man-in-the-middle DRDA server could craft a response with a 0x50-tagged column, causing the client to deserialize arbitrary attacker-controlled bytes on the Vert.x event loop before any application code can inspect or reject the data. If a Java deserialization gadget chain is present on the application's classpath, this enables remote code execution. Without a gadget chain, denial of service is possible via crafted object graphs. TLS is disabled by default, making man-in-the-middle exploitation feasible.
The impacted component is io.vertx:vertx-db2-client.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using the io.vertx:vertx-db2-client in the affected version ranges are exposed when they connect to a malicious DRDA server or when an attacker can intercept and alter DRDA traffic. The vulnerable parsing occurs before application code can validate the returned data.
Can a legitimate DB2 server trigger the vulnerable deserialization path?
No. The path requires a result-set column tagged with FDOCA LID 0x50, which DB2 does not send because it does not support this UDT type. Exploitation therefore requires a malicious server response or manipulation of traffic in transit.
What is required for remote code execution?
The attacker must cause the client to process a crafted 0x50-tagged DRDA column and a usable Java deserialization gadget chain must be present on the application's classpath. Without such a gadget chain, crafted object graphs can still cause denial of service.
Is a default deployment vulnerable to man-in-the-middle exploitation?
TLS is disabled by default, so deployments that use the default transport settings may permit an attacker able to intercept DRDA traffic to inject a malicious response. Enabling TLS can reduce the man-in-the-middle exposure.