CVE-2026-102464

In Eclipse Vert.x versions [5.0.0,5.0.12], [5.1.0,5.1.9], and [5.2.0, 5.2.0], the Vert.x HTTP client relies on an SSL context cache whose key does not fully reflect the SSL semantics of the desired properties. A client can request an SSL context and receive one with weaker properties, for example a context ignoring hostname validation instead of one with hostname validation. The impacted component is io.vertx:vertx-core.

In Eclipse Vert.x (vertx-grpc-server module), the configurable maximum message size limit for gRPC is applied to the compressed size rather than the actual uncompressed content size. This allows an attacker to send a compressed message that expands to far more memory than the configured limit.

In the Eclipse Vert.x MySQL client (vertx-mysql-client), the column definition array is pre-allocated based on a server-declared column count with no upper-bound validation. A malicious or compromised MySQL server (or a man-in-the-middle attacker) can send a crafted packet with an extremely large column count, causing a massive heap allocation.

In the binary array decoder of the Eclipse Vert.x PostgreSQL client (vertx-pg-client, DataTypeCodec.binaryDecodeArray), a Java array is allocated based on a server-declared 32-bit dimension count with no upper bound. A malicious or compromised PostgreSQL server (or an on-path attacker on an unencrypted connection) can send a crafted DataRow message with an excessively large array dimension value.

In the TDS message decoder of the Eclipse Vert.x MSSQL client (vertx-mssql-client), inbound TDS packets are aggregated into a composite direct-memory buffer without any cumulative size limit. A malicious, compromised, or man-in-the-middle SQL Server can send a continuous stream of TDS packets without setting the END_OF_MESSAGE status flag.

In Eclipse Vert.x, the uniqueItems keyword validation (vertx-json-schema module) uses an O(n²) pairwise comparison loop with no short-circuit or size limit. A remote unauthenticated attacker can submit a moderately-sized JSON array that consumes disproportionate CPU time.

In Eclipse Vert.x (vertx-http-proxy module), the body transformer interceptor relies on a max buffered bytes limit to ensure a bounded buffer for each request. This can be used to force a server to indefinitely allocate heap. The vulnerability requires the use of an intercepting body transformer.

In Eclipse Vert.x versions [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9], and [5.2.0, 5.2.0], the WebSocket implementation does not define a maximum number of bytes allocated when decompressing frames or messages. This allows a zip bomb style denial-of-service attack.

In Eclipse Vert.x versions [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9], and [5.2.0, 5.2.0], the Vert.x Redis client RESP parser pre-allocates arrays to a length declared by the server without enforcing an upper bound. A malicious or compromised Redis server, or a man-in-the-middle attacker, can send a crafted RESP response declaring an extremely large array, push, or attribute length, causing the client to attempt a massive heap allocation.

The Vert.x HTTP/1.x decoder in versions [5.0.0,5.0.12], [5.1.0,5.1.9], and [5.2.0,5.2.0] uses canonicalization for well-known HTTP headers that misinterprets crafted headers as listed headers, e.g., Content-Xength as Content-Length. This enables request smuggling attacks.