CVE-2024-1300: Eclipse Vert.x TCP Server DOS Vulnerability

CVE-2024-1300 Overview

CVE-2024-1300 is a memory leak vulnerability in the Eclipse Vert.x toolkit affecting TCP servers configured with TLS and Server Name Indication (SNI) support. When a client sends a TLS ClientHello containing an unknown SNI server name, Vert.x assigns the default certificate but erroneously caches the SSL context in the server name map. Repeated requests with unique fake server names cause unbounded growth of this cache, eventually exhausting JVM heap memory.

The flaw is tracked under CWE-772: Missing Release of Resource after Effective Lifetime and impacts services exposed through Vert.x networking components, including downstream Red Hat middleware products.

Critical Impact
Remote attackers can trigger a Java Virtual Machine (JVM) out-of-memory condition by flooding a Vert.x TLS endpoint with TLS client hello messages containing arbitrary SNI server names.

Affected Products

Eclipse Vert.x toolkit (TCP servers configured with TLS and SNI)
Red Hat build of Quarkus and related middleware bundling vulnerable Vert.x versions (see Red Hat Security Advisories RHSA-2024:1662, 1706, 1923, 2088, 2833, 3527, 3989, 4884)
Java applications and reactive frameworks embedding the vulnerable io.vertx:vertx-core library

Discovery Timeline

2024-04-02 - CVE-2024-1300 published to the National Vulnerability Database (NVD)
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-1300

Vulnerability Analysis

The vulnerability resides in how Vert.x handles SNI negotiation during the TLS handshake. SNI allows a client to specify the hostname it intends to reach so that the server can present the matching certificate. Vert.x maintains an internal map that associates server names with their corresponding SSL contexts to avoid recomputing context lookups for repeated connections.

When a client supplies a server name that does not match any configured mapping, Vert.x falls back to the default certificate. The defect is that the resulting SSL context is still inserted into the server name cache keyed by the attacker-supplied name. Because attackers control the SNI field and can generate an effectively unlimited number of unique values, each new connection adds a new entry that is never evicted.

The outcome is denial of service through memory exhaustion. The Vert.x process consumes heap until the JVM throws OutOfMemoryError, terminating request processing for legitimate clients.

Root Cause

The root cause is improper cache key validation combined with a missing resource release path. The SNI lookup logic conflates two distinct outcomes — a known server name and an unknown server name resolved to the default certificate — and stores both in the same unbounded map. There is no upper bound on cache size and no expiration policy, satisfying the conditions described in CWE-772.

Attack Vector

Exploitation requires only network reach to a Vert.x TLS listener. An attacker opens TLS connections and varies the server_name extension in each ClientHello, for example by generating random subdomain strings. Each connection forces the server to allocate and cache a context entry. Sustained traffic from a single client, or a small distributed set of clients, is sufficient to drive the JVM into an out-of-memory state.

No authentication is required at the TLS layer for the leak to occur, although the CVSS vector reflects that some adjacent privilege context applies in certain deployment scenarios. Standard TLS scanning tools or a short script using OpenSSL s_client with a varying -servername argument can reproduce the behavior.

No verified public proof-of-concept exploit code is available. See the Red Hat CVE-2024-1300 advisory and the Vert.x SNI documentation for protocol-level details.

Detection Methods for CVE-2024-1300

Indicators of Compromise

Sustained growth of JVM heap usage on Vert.x processes that correlates with inbound TLS connections rather than application workload
High volume of TLS handshakes containing unique or randomized SNI server_name values from a small set of source IP addresses
java.lang.OutOfMemoryError: Java heap space entries in Vert.x application logs following periods of TLS traffic
Increasing object counts for SSL context entries when sampling heap dumps with tools such as jmap or jcmd

Detection Strategies

Inspect TLS traffic at the network edge for clients sending many handshakes with non-resolvable or pseudo-random SNI names to a single listener
Enable JVM garbage collection and heap metrics in Vert.x services and alert when heap-after-GC trends upward without corresponding request growth
Compare the cardinality of distinct SNI values per source IP against a baseline of legitimate client behavior

Monitoring Recommendations

Export jvm_memory_used_bytes and jvm_gc_pause_seconds metrics from Vert.x applications to a central observability platform
Capture TLS handshake metadata at load balancers or reverse proxies to track SNI cardinality over time
Configure alerts on repeated OutOfMemoryError exceptions and on container restarts triggered by memory limits in Kubernetes or OpenShift

How to Mitigate CVE-2024-1300

Immediate Actions Required

Inventory all Java services that embed io.vertx:vertx-core and identify any with TLS plus SNI enabled on public-facing listeners
Apply vendor-supplied updates from Eclipse Vert.x and from Red Hat advisories RHSA-2024:1662, 1706, 1923, 2088, 2833, 3527, 3989, and 4884 to affected middleware
Restart Vert.x processes after patching to clear any cached SSL context entries accumulated before the fix

Patch Information

Fixed versions of Eclipse Vert.x correct the SNI cache logic so that lookups resolving to the default certificate are no longer inserted into the server name map. Red Hat has shipped patched builds across multiple product streams. Refer to Red Hat Security Advisory RHSA-2024:1662 and the accompanying advisories listed in the references for product-specific patched component versions, and consult Red Hat Bug #2263139 for the upstream fix discussion.

Workarounds

Disable SNI on Vert.x TCP/HTTP servers where multiple certificates are not required, forcing all clients to negotiate against a single default certificate
Terminate TLS at an upstream proxy such as HAProxy, Envoy, or NGINX that is not affected by this defect, and forward plaintext or re-encrypted traffic to Vert.x on a trusted network
Enforce rate limiting and connection caps per source IP at the network edge to slow the growth of any residual SNI cache while patches are deployed
Set conservative JVM heap limits and configure container orchestration to restart pods on OutOfMemoryError, reducing the blast radius until remediation completes

bash

# Configuration example: disable SNI on a Vert.x HttpServerOptions instance
# HttpServerOptions options = new HttpServerOptions()
#     .setSsl(true)
#     .setSni(false)
#     .setKeyCertOptions(keyCertOptions);