Listen to this Post
When server-side SNI is enabled in a Vert.x application, the TLS engine uses a cache to map SNI hostnames presented by clients to the appropriate `SslContext` (the security context for that connection). This cache is implemented as a standard `ConcurrentHashMap` and is populated using computeIfAbsent(serverName, ...). Critically, the cache lacks any built-in bounds, eviction policy, or time-to-live (TTL). If the server is configured with a wildcard certificate (e.g., .example.com), any subdomain name (a.example.com, b.example.com, etc.) will be considered a match. An unauthenticated attacker can exploit this by sending a large number of TLS handshake requests, each with a unique, but still matching, SNI name. Each unique name forces the server to generate a new `SslContext` and store it in the cache, permanently consuming memory. Over time, this unbounded growth leads to memory exhaustion, causing the Java Virtual Machine (JVM) to crash or the service to become unresponsive—a classic Denial-of-Service (DoS) condition. The issue is present in versions 4.3.4 through 5.0.8, specifically impacting the `SSLHelper` (4.3.x), `SslChannelProvider` (4.4.x/4.5.x), and `SslContextProvider` (5.0.x) classes. A fix is implemented in versions 4.5.26 and 5.0.9, replacing the unbounded `ConcurrentHashMap` with an LRU (Least Recently Used) cache that has a maximum default size of 16 entries.
Platform: Eclipse Vert.x
Version: 4.3.4 – 5.0.8
Vulnerability : Unbounded SNI Cache
Severity: Medium
date: 2026-05-06
Prediction: 2026-05-06 (patch 4.5.26/5.0.9)
Analytics under heading What Undercode Say:
Check your Vert.x version in a Maven project
grep vertx.version pom.xml
Reproduce the issue: Send unique SNI names to a server using a wildcard cert
for i in {1..100}; do
echo "Q" | openssl s_client -connect localhost:443 -servername sub$i.example.com 2>/dev/null | grep "Verify return code"
done
Monitor memory usage of the Vert.x process in real-time
watch -n 1 ps aux | grep vertx
Example VERT.x code that triggers the vulnerability
NetServerOptions options = new NetServerOptions()
.setSsl(true)
.setSni(true)
.setKeyCertOptions(new PemKeyCertOptions()
.addKeyPath("wildcard-key.pem")
.addCertPath("wildcard-cert.pem"));
vertx.createNetServer(options).connectHandler(sock -> {
sock.handler(buff -> {
sock.write("Hello");
});
}).listen(443);
Exploit:
An attacker uses a script to establish thousands of TLS connections, each time presenting a new, distinct SNI hostname that still matches the server’s wildcard certificate (e.g., attack-1.example.com, attack-2.example.com, …). The server, unable to find the name in its cache, generates a new `SslContext` for each new name and stores it permanently. This rapidly consumes available heap memory, leading to high CPU usage from garbage collection and eventually a JVM crash, rendering the service unavailable.
Protection from this CVE
- Disable SNI: If not required, disable SNI entirely in your Vert.x server configuration.
- Avoid Wildcard Certificates: Use explicit certificate mappings for each expected hostname rather than broad wildcards (“).
- Deploy a WAF/Rate Limiter: Place a reverse proxy or load balancer in front of the Vert.x service to limit the number of connections per IP address.
- Patch Immediately: Upgrade to Vert.x versions
4.5.26,5.0.9, or any later release where the bounded SNI cache is implemented.
Impact:
Denial of Service (DoS). Successful exploitation leads to uncontrolled memory consumption (memory exhaustion) on the server. This will crash the application process, making the service unavailable to all legitimate users. No authentication or privileges are required to trigger the attack, and it can be launched remotely over the network.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
