CVE-2024-1300

What it actually does

Memory leak occurs when TLS servers using SNI cache SSL contexts for unknown server names mapped to the default certificate instead of discarding them, eventually exhausting JVM heap.

Why it matters to the business

Production TLS endpoints can become unavailable due to out-of-memory crashes, interrupting services and requiring restarts or scaling events until the root cause is addressed.

How an attack unfolds

An attacker repeatedly connects to a Vert.x TCP server configured with TLS and SNI, supplying client hello messages containing arbitrary unknown server names; each connection causes an SSL context to be erroneously retained in the server name map, steadily consuming memory until the JVM terminates with an out-of-memory error.

How to fix it

Upgrade Eclipse Vert.x to a release that corrects the SNI server-name-map caching behavior; if an upgrade is not immediately feasible, disable SNI or restrict the set of accepted server names to reduce the attack surface.

How to confirm the fix worked

After applying the update, confirm that memory usage remains stable under a test load of unknown SNI client hellos and that no SSL contexts accumulate in heap dumps for unmapped names.

Typical attack path

1. Scan for publicly reachable Vert.x TLS endpoints that advertise SNI support
2. Generate TLS client hello messages containing random or attacker-chosen server names not present in the configured certificate map
3. Establish repeated connections at a rate sufficient to trigger repeated caching of default-certificate contexts
4. Monitor target memory consumption or wait for JVM OOM termination to confirm successful resource exhaustion

How to detect it

Search application and JVM logs for repeated OutOfMemoryError events correlated with TLS handshake activity; inspect connection logs for high volumes of client hellos containing server names absent from the configured certificate map.

• java.lang.OutOfMemoryError.*SSL
• unknown SNI server name
• Vertx.*SNI.*cache

What your security team should do

• Apply the Vert.x patch or configuration change within the next maintenance window given the public availability of the flaw
• Add JVM heap and connection-rate monitoring for all TLS Vert.x instances to detect anomalous memory growth
• Review TLS server configurations to ensure only expected SNI names are mapped and the default certificate path is minimized