Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Potential unbounded server-side SNI SslContext cache growth in Vert.x TLS handling, with = resource-exhaustion / DoS impact. On affected versions, matching server-side SNI names are cached via computeIfAbsent(serverName, ...) in a serverName-keyed SslContext cache. The implementation differs slightly by branch, but the same sink appears to be present in released versions 4.3.4 through 5.0.11: - 4.3.x: SSLHelper - 4.4.x / 4.5.x: SslChannelProvider - 5.0.x and current master: SslContextProvider When server-side SNI is enabled and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of SslContext entries over time, leading to increasing memory consumption and possible DoS conditions. Steps to reproduce 1. Configure a Vert.x server with setSsl(true) and setSni(true). 2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule. 3.…
Recommended action: Upgrade to 5.0.12 or 4.5.27 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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);
Recommended action: Upgrade to 5.0.7 or 4.5.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.5.3 or 4.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.5.2 or 4.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In version from 3.5.Beta1 to 3.5.3 of Eclipse Vert.x, the OpenAPI XML type validator creates XML parsers without taking appropriate defense against XML attacks. This mechanism is exclusively when the developer uses the Eclipse Vert.x OpenAPI XML type validator to validate a provided schema.
Recommended action: Upgrade to 3.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.