Eclipse Vert.x CVE-2026-102465

The target application must use the Eclipse Vert.x Redis client (io.vertx:vertx-redis-client) in an affected version [4.0.0-4.5.34], [5.0.0-5.0.12], [5.1.0-5.1.9], or 5.2.0, and must connect to a Redis server that the attacker controls/has compromised, OR the attacker must occupy a man-in-the-middle position on the client-to-Redis network path. Exploitation is LIMITED by these prerequisites: a trusted, authenticated Redis instance on an isolated network with TLS-protected transport (preventing MITM) is not exploitable by an external unauthenticated party - this is why the vector carries AC:H despite PR:N. No end-user interaction is required.

This is a genuine but conditional denial-of-service issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N) scores 8.2 largely because of VA:H (full availability loss of the event loop) combined with network reach and no authentication, but the AC:H flag is the decisive signal: exploitation requires the attacker to either control/compromise the Redis server the client connects to, or hold a man-in-the-middle position on that connection. That is a meaningful barrier against a properly segmented, TLS-protected Redis deployment. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no evidence of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis.' The impact is pure availability (VC:N/VI:N/VA:H - no confidentiality or integrity loss), and the OutOfMemoryError crashes the shared Vert.x event loop, amplifying blast radius to all connections and verticles on that loop. Net: a real priority for teams whose Vert.x apps connect to untrusted or externally-reachable Redis endpoints, but a low-urgency, patch-on-cadence issue for those with trusted, network-isolated Redis. One data conflict must be verified: the description and CPE concern the Vert.x Redis client, but the 'impacted component' field names io.vertx:vertx-mysql-client, which is inconsistent - confirm the affected Maven coordinate with the vendor advisory before remediation.

A Vert.x application is configured to connect to a Redis endpoint that an attacker controls or can intercept (e.g., a compromised shared cache or an unencrypted Redis link an on-path attacker can tamper with). The attacker returns a crafted RESP response declaring an enormous array/push/attribute length; the client pre-allocates a correspondingly massive heap buffer, triggers an OutOfMemoryError, and crashes the event loop thread - taking down every connection and verticle sharing that loop. No public proof-of-concept was provided in the input.