WaratekVRT Sign in

Medium Io.vertx CVEs

10 CVEs, 1 protected by Waratek

Reset
More filters (1)
Columns
Vendor io.vertx✕
Overview 10 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
10matches 1protected10.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 1 10.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 9 90.0%
Critical 0 0.0% High 0 0.0% Medium 10 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 10.0% partly blocked 0 0.0% not blocked 9 90.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 5 50.0% Forecast only 0 0.0% No public exploit 5 50.0%
split by peak 3 / year
No exploit published: 9Protected by Waratek: 1 Medium: 10 not blocked: 9blocked by ARMR today: 1 No public exploit: 5Proof of concept only: 5
20182 No exploit published2 Medium2 not blocked2 No public exploit2 20190 20200 20210 20220 20232 Protected by Waratek1 No exploit published1 Medium2 blocked by ARMR today1 not blocked1 Proof of concept only1 No public exploit1 20243 No exploit published3 Medium3 not blocked3 Proof of concept only1 No public exploit2 20251 No exploit published1 Medium1 not blocked1 Proof of concept only1 20262 No exploit published2 Medium2 not blocked2 Proof of concept only2
201820192020202120222023202420252026
10 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-2026-6860 Medium 2026-05-06 No exploit published Proof of concept only A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used.
CVE-2026-1002 Medium 2026-01-15 No exploit published Proof of concept only The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI. The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895 Steps to reproduce Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html Mitgation Disabling Static Handler cache fixes the issue. StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);
CVE-2025-11965 Medium 2025-10-22 No exploit published Proof of concept only 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').
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-2024-1023 Medium 2024-03-27 No exploit published Proof of concept only A vulnerability in the Eclipse Vert.x toolkit results in a memory leak due to using Netty FastThreadLocal data structures. Specifically, when the Vert.x HTTP client establishes connections to different hosts, triggering the memory leak. The leak can be accelerated with intimate runtime knowledge, allowing an attacker to exploit this vulnerability. For instance, a server accepting arbitrary internet addresses could serve as an attack vector by connecting to these addresses, thereby accelerating the memory leak.
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-2023-24815 Medium 2023-02-09 Protected by Waratek Proof of concept only Vert.x-Web is a set of building blocks for building web applications in the java programming language. When running vertx web applications that serve files using `StaticHandler` on Windows Operating Systems and Windows File Systems, if the mount point is a wildcard (`*`) then an attacker can exfiltrate any class path resource. When computing the relative path to locate the resource, in case of wildcards, the code: `return "/" + rest;` from `Utils.java` returns the user input (without validation) as the segment to lookup. Even though checks are performed to avoid escaping the sandbox, given that the input was not sanitized `\` are not properly handled and an attacker can build a path that is valid within the classpath. This issue only affects users deploying in windows environments and upgrading is the advised remediation path. There are no known workarounds for this vulnerability.
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.