CVE-2026-102466

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 MQTT client (vertx-mqtt), MqttClient stores every inbound QoS 2 PUBLISH message in an internal map (qos2inbound) while awaiting the corresponding PUBREL packet. This map has no size limit, and the maxInflightQueue option only constrains the outbound path.

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.