Eclipse Vert.x vulnerabilities

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 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.

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, the vertx-mail-client does not sanitize CR/LF characters in user-supplied email header names and values before writing them to the SMTP DATA section. Injecting CR/LF sequences allows adding arbitrary headers (e.g., Bcc, Reply-To) or prepending body content; the same weakness affects MIME part metadata.

In Eclipse Vert.x up to versions 4.5.29 (4.x) and 5.1.4 (5.x), the DefaultRedirectHandler (vertx-core) forwards all request headers, including credential headers (Authorization, Cookie, Proxy-Authorization) and custom headers (e.g., X-API-Token), during cross-origin HTTP 30x redirects. No origin comparison (scheme, host, port) is performed before copying headers to the redirect target.

In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], when directory listing is enabled, file and directory names are inserted into generated HTML without proper escaping in href, title, and link attributes. An attacker who can create or rename files in a served path can trigger stored XSS.

In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], a StaticHandler configuration for restricting access to hidden files fails to restrict access to hidden directories, allowing unauthorized users to retrieve files within them (e.g. '.git/config').

A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support. When processing an unknown SNI server name assigned the default certificate instead of a mapped certificate, the SSL context is erroneously cached in the server name map, leading to memory exhaustion. Attackers can send TLS client hello messages with fake server names, triggering a JVM out-of-memory error.

A vulnerability in the Eclipse Vert.x toolkit results in a memory leak due to using Netty FastThreadLocal data structures. The leak occurs when the Vert.x HTTP client establishes connections to different hosts, and can be accelerated by an attacker with intimate runtime knowledge. A server accepting arbitrary internet addresses could serve as an attack vector by connecting to these addresses, thereby accelerating the memory leak.