WaratekVRT Sign in

Medium Io.vertx CVEs with no public exploit

5 CVEs

Reset
More filters (1)
Columns
Vendor io.vertx✕
Overview 5 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
5matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 5 100.0%
Critical 0 0.0% High 0 0.0% Medium 5 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 5 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 5 100.0%
split by peak 2 / year
No exploit published: 5 Medium: 5 not blocked: 5 No public exploit: 5
20182 No exploit published2 Medium2 not blocked2 No public exploit2 20190 20200 20210 20220 20231 No exploit published1 Medium1 not blocked1 No public exploit1 20242 No exploit published2 Medium2 not blocked2 No public exploit2
2018201920202021202220232024
5 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2024-8391 Medium 2024-09-04 No exploit published No public exploit In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client).  This is fixed in the 4.5.10 version.  Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc)
CVE-2024-1300 Medium 2024-04-02 No exploit published No public exploit 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. This flaw allows attackers to send TLS client hello messages with fake server names, triggering a JVM out-of-memory error.
CVE-2023-32081 Medium 2023-05-12 No exploit published No public exploit Vert.x STOMP is a vert.x implementation of the STOMP specification that provides a STOMP server and client. From versions 3.1.0 until 3.9.16 and 4.0.0 until 4.4.2, a Vert.x STOMP server processes client STOMP frames without checking that the client send an initial CONNECT frame replied with a successful CONNECTED frame. The client can subscribe to a destination or publish message without prior authentication. Any Vert.x STOMP server configured with an authentication handler is impacted. The issue is patched in Vert.x 3.9.16 and 4.4.2. There are no trivial workarounds.
CVE-2018-12541 Medium 2018-10-10 No exploit published No public exploit In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.
CVE-2018-12537 Medium 2018-08-14 No exploit published No public exploit In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response.