CVE-2026-6860: Unbounded SNI Cache Growth in Eclipse Vert.x

Eclipse Vert.x is a reactive toolkit for the Java Virtual Machine (JVM) designed to handle highly concurrent network operations. It provides extensive support for TLS termination and configuration. Server Name Indication (SNI) is a TLS extension specified in RFC 6066 that allows a client to indicate the hostname it is attempting to connect to at the start of the handshaking process.

The vulnerability exists in the internal caching implementation responsible for storing TLS SslContext instances. When server-side SNI is enabled via configuration, Vert.x inspects the ClientHello message to extract the requested server name. It then dynamically resolves and provisions the appropriate TLS context for that specific hostname.

To avoid the computational overhead of generating a new SslContext for every incoming connection, Vert.x caches these objects. The cache uses the extracted SNI hostname string as the primary lookup key. This architectural decision introduces a critical flaw because the underlying cache map does not enforce an upper size limit or a time-to-live (TTL) eviction policy.

The vulnerability manifests when the server is configured with a broad certificate, specifically a wildcard certificate such as *.example.com. Under this configuration, the server considers any matching subdomain string to be valid. An unauthenticated remote attacker can exploit this by programmatically opening TCP connections and completing the initial phase of the TLS handshake using continuously changing, randomly generated SNI names.

The root cause of CVE-2026-6860 is an Uncontrolled Resource Consumption (CWE-400) flaw in the internal state management of the Vert.x networking stack. The framework relies on standard Java concurrent collections to store runtime session data. Specifically, the implementation utilizes a ConcurrentHashMap to associate SNI strings with their corresponding SslContext objects.

The vulnerability is triggered within the cache lookup logic. The code leverages the Map.computeIfAbsent(Object key, Function mappingFunction) method. When a new connection arrives, the networking layer extracts the SNI string and checks the map. If the string is not present, the mapping function executes to instantiate a new SslContext, which is then stored in the map indefinitely.

Because wildcard certificates successfully validate against any arbitrary string that matches the domain pattern, the mappingFunction will successfully execute and return a valid context. The system lacks any mechanism to detect or limit high-cardinality insertions. Every unique string generates a distinct heap allocation that is strongly referenced by the map, preventing the Java Garbage Collector from reclaiming the memory.

The memory footprint of an SslContext is non-trivial. Depending on the underlying JSSE (Java Secure Socket Extension) or OpenSSL/BoringSSL implementation via netty-tcnative, each context object holds certificate chains, private key references, and associated cryptographic parameters. Continuous allocation of these objects rapidly consumes available JVM heap space.

The vulnerability affects different internal classes depending on the Vert.x version branch. In 4.3.x, the sink is located in io.vertx.core.net.impl.SSLHelper. In later versions (4.4.x and 4.5.x), the logic moved to io.vertx.core.net.impl.SslChannelProvider. In the 5.0.x and master branches, the responsible class is io.vertx.core.net.impl.SslContextProvider.

The vulnerable design pattern relies on an unbounded cache mapped directly to untrusted client input. The original implementation can be conceptualized as follows:

// VULNERABLE PATTERN
private final Map<String, SslContext> serverContexts = new ConcurrentHashMap<>();
 
public SslContext getContext(String serverName) {
    // Extracted serverName from SNI extension is passed directly as the key
    // An attacker can specify arbitrary strings matching a wildcard cert
    return serverContexts.computeIfAbsent(serverName, this::createSslContext);
}

The fix introduced in Pull Request #6102 fundamentally alters this design by replacing the unbounded ConcurrentHashMap with a bounded Least Recently Used (LRU) cache structure. This ensures that the total memory allocated for TLS contexts remains fixed, regardless of the number of unique hostnames requested by clients.

// PATCHED PATTERN
// The maximum number of distinct contexts is now strictly bounded
private final LRUCache<String, SslContext> serverContexts = new LRUCache<>(MAX_CACHE_SIZE);
 
public SslContext getContext(String serverName) {
    // The getOrAdd method implements LRU eviction rules.
    // Once MAX_CACHE_SIZE is reached, the oldest unused entry is discarded.
    return serverContexts.getOrAdd(serverName, this::createSslContext);
}

The implementation of the LRU cache allows the JVM Garbage Collector to safely reclaim the memory associated with evicted SslContext objects. This completely eliminates the uncontrolled growth vector while preserving the performance benefits of caching for legitimate, repeated hostname requests.

Exploitation of CVE-2026-6860 requires low complexity and no prior authentication. The attacker must only possess network routability to the target server's TLS-enabled port. The primary prerequisite is that the target server is configured to evaluate server-side SNI and utilizes a certificate that validates multiple arbitrary hostnames, most commonly a wildcard certificate.

The attack begins with the generation of an automated script to handle TCP connection initiation. The script opens a standard TCP socket and transmits the first segment of the TLS protocol: the ClientHello. The payload is crafted to include the SNI extension (Type 0) populated with a randomly generated string appended to the base domain, such as a1b2c3d4.example.com.

To maximize impact while minimizing the attacker's own resource utilization, the exploit script will terminate the TCP connection immediately after transmitting the ClientHello and receiving the ServerHello acknowledgment. Completing the full cryptographic handshake is unnecessary. The memory allocation on the target occurs during the initial inspection of the incoming SNI extension.

By parallelizing this connection teardown sequence across multiple threads, an attacker can push tens of thousands of unique ClientHello messages per second. The repeated generation of unique hostname strings guarantees a cache miss on every request, bypassing any optimizations and forcing raw memory allocation inside the target process.

The direct impact of this vulnerability is a severe degradation of application availability. As the ConcurrentHashMap continues to grow, it claims an increasing percentage of the JVM heap space. The objects stored within the map are strongly referenced, meaning they cannot be collected during standard memory management cycles.

As available heap space diminishes, the JVM experiences extreme memory pressure. This triggers the Garbage Collector to initiate frequent Stop-The-World (STW) pauses in an attempt to reclaim memory. During a STW pause, all application threads are suspended. This behavior introduces severe latency into the application, causing it to drop incoming connections and fail health checks.

Eventually, the heap becomes completely saturated. When the JVM can no longer allocate memory for either new connections or standard application processing, it throws a java.lang.OutOfMemoryError (OOM). Depending on the host operating system and JVM configuration, this error will either cause the entire Java process to crash abruptly or leave it in a zombie state where it consumes CPU resources but fails to process legitimate traffic.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L yielding a base score of 5.3 (Medium). However, the CVSS v4.0 assessment rates the vulnerability at 6.9 (Medium). The availability impact is confined solely to the specific server component hosting the Vert.x instance. There is no confidentiality or integrity risk associated with this flaw.

The most effective remediation strategy is to upgrade the io.vertx:vertx-core dependency to a patched version. The maintainers have backported the fix across all actively supported release branches. Organizations must update their build configurations to utilize versions 4.3.9, 4.4.10, 4.5.27, or 5.0.12 or greater, depending on their respective release stream.

If an immediate upgrade is not feasible due to deployment constraints, several temporary mitigations exist. The primary workaround is to disable server-side SNI configuration if the application architecture does not strictly require it. This is achieved by invoking setSni(false) on the HttpServerOptions or NetServerOptions object during server initialization.

Another architectural mitigation involves offloading TLS termination to a dedicated reverse proxy or load balancer located at the network perimeter. Infrastructure components like HAProxy, Nginx, or AWS Application Load Balancers can terminate the TLS session and validate the SNI extension before passing unencrypted HTTP traffic to the backend Vert.x service. This isolates the vulnerable JVM process from malicious handshake requests.

Finally, strict rate limiting can be implemented at the firewall or web application firewall (WAF) layer. Restricting the number of new TLS handshakes permitted per second from a single source IP address will significantly slow down the rate of memory consumption, providing operational teams with sufficient time to detect and block the anomalous traffic patterns.