Vert.x DB2 Client CVE-2026-102469

Exploitation requires that the application use the io.vertx:vertx-db2-client in an affected version AND connect to a DRDA server the attacker controls or can man-in-the-middle; the trigger is a server-sent result-set column tagged with FDOCA UDT type LID 0x50, which legitimate DB2 servers never emit. Because client-side TLS is disabled by default, a network attacker on the client-to-DB2 path can inject the malicious response without first compromising credentials. Full remote code execution additionally requires a Java deserialization gadget chain on the application classpath; without one, impact is limited to denial of service. Limiting factors: attacker must hold server-side or MITM position (AC:H), and RCE depends on classpath gadget availability - deployments using TLS/mutual auth to a trusted DB2 server are not practically exploitable.

This is a genuine high-priority issue for the specific population that uses it, but its real-world blast radius is narrower than the 9.2 CVSS 4.0 score suggests in isolation. The vendor vector (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) correctly captures network reach with no authentication or user interaction against the client, but critically marks AC:H - exploitation is NOT trivial opportunistic hitting of a listening service. The attacker must either operate a malicious DRDA/DB2 server the client connects to, or hold a man-in-the-middle position on the client-to-DB2 path; the advisory notes TLS is disabled by default, which makes that MITM position realistically attainable on untrusted networks. Full remote code execution is further gated on a deserialization gadget chain being present on the application classpath - a real but not universal precondition; absent a gadget chain the impact degrades to denial of service via malicious object graphs, which still matters because deserialization occurs on the Vert.x event loop before application code can reject it. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active exploitation - this is a disclosed vulnerability (reported by Eclipse via GHSA advisory), not a known exploited one. Signals are therefore consistent rather than conflicting: high theoretical impact, moderate attack complexity, no observed exploitation. Treat as a prioritized patch for teams running io.vertx:vertx-db2-client, especially those connecting over untrusted networks without TLS, rather than an emergency broad-internet threat.

An attacker who controls a DB2/DRDA endpoint or can intercept an unencrypted client connection (TLS is off by default) returns a crafted result set containing a column tagged as a UDT with FDOCA type LID 0x50. The Vert.x DB2 client blindly calls ObjectInputStream.readObject() on the attacker-supplied bytes on the event loop, and if a Java deserialization gadget chain exists on the classpath this yields remote code execution; otherwise a malicious object graph causes denial of service. No public exploit was identified at time of analysis, but the deserialization sink is well-understood and gadget-chain tooling is widely available.