In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the WebSocket implementation does not define a maximum number of bytes allocation when decompressing frames or messages. This can be used to implement DDOS attacks with a zip bomb.
The impacted component is io.vertx:vertx-core.
In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length.
This can be exploited for request smuggling purpose.
The impacted component is io.vertx:vertx-core.
In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP client relies on an SSL context for efficiency purpose, the key of this cache should reflect entirely the SSL semantics of the desired SSL properties. It is possible for a client to ask for an SSL context and obtain an SSL context with weaker properties, for instance a context with hostname validation and obtain a context ignoring hostname validation.
The impacted component is io.vertx:vertx-core.
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').
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 the href, title, and link attributes. An attacker who can create or rename files or directories within a served path can craft filenames containing malicious script or HTML content, leading to stored cross-site scripting (XSS) that executes in the context of users viewing the affected directory listing.
Since Vert.x 4.3.4 that leads to a memory leak when a TCP server is configured with TLS and SNI support: when such server processes an unknown SNI server name, that is a server name that would be assigned the default certificate instead of a server name mapped certificate, the SSL context will be cached in the server name map. This map should only contain server names for which the configuration provides a valid certificate. As a consequence, this can be exploited by client sending TLS client hello message with the server name extension indicating spurious server names and eventually trigger a JVM out of memory error.
This affects only TLS servers with SNI enabled https://vertx.io/docs/vertx-core/java/#servernameindicationsni.
It affects the maven artifact io.vertx:vertx-core versions 4.3.4,4.3.5,4.3.6,4.3.7,4.3.8,4.4.0,4.4.1,4.4.2,4.4.3,4.4.4,4.4.5,4.4.6,4.4.7,4.5.0,4.5.1,4.5.2
https://github.com/eclipse-vertx/vert.x/pull/5101 [Master] https://github.com/eclipse-vertx/vert.x/pull/5100 [4.x] https://github.com/eclipse-vertx/vert.x/pull/5099 [4.3]
There is a regression in Vert.x 4.4 branch that leads to a memory leak due to the use of Netty FastThreadLocal data structures.
As a consequence, when the Vert.x HTTP client connects to a different host, it does make the leak progress furthermore, there might be other cases leading to the same effect but exhibiting one seems enough to demonstrate the feasability.
Thus, this can be exploited with intimate knowledge of the runtime to accelerate the memory leak, e.g. a server accepting arbitrary internet addresses for which it will connect to could be fed with addresses as an attack vector.
This affects the maven artifact io.vertx:vertx-core versions 4.4.5, 4.4.6, 4.5.0, 4.5.1
https://github.com/eclipse-vertx/vert.x/issues/5078 https://github.com/eclipse-vertx/vert.x/pull/5082 https://github.com/eclipse-vertx/vert.x/pull/5080