Eclipse Vert.x CVE-2026-102476

Exploitation requires the target application to use the Vert.x HTTP client and to create more than one SSL context whose desired properties differ in a way the cache key does not distinguish - specifically mixing a context that enables hostname (endpoint identification) validation with one that disables it - so that a request intended to validate hostnames is served the weaker cached context. It additionally requires the attacker to hold an active man-in-the-middle network position to abuse the resulting loss of certificate/hostname verification. Limiting factors: applications that use a single uniform SSL configuration, or that never disable hostname validation, are not exposed; there is no user interaction and no authentication requirement (PR:N/UI:N), but the AC:H rating reflects the dependency on this specific context-mixing configuration plus a network interception capability.

This is a TLS trust-decision flaw in Eclipse Vert.x's HTTP client SSL context cache (io.vertx:vertx-core), where the cache key fails to capture the full SSL semantics of requested properties, so a caller requesting a context with hostname validation can receive a cached context that ignores it. The input CVSS 4.0 vector (AV:N/AC:H/PR:N/UI:N, VC:H/VI:H) scores 9.1 and reflects high confidentiality and integrity impact reachable over the network without authentication, but AC:H correctly signals that exploitation is not trivial: it depends on an application configuring multiple SSL contexts with differing security properties that collide on the cache key, plus an attacker positioned to perform a man-in-the-middle interception once validation is silently downgraded. No EPSS score, KEV listing, or POC is provided in the input, and there is no public exploit identified at time of analysis - so despite the high CVSS this is best treated as a serious latent weakening of TLS guarantees rather than an actively-exploited priority. The headline score is driven by worst-case MITM impact; the real-world probability is gated by whether a given deployment actually mixes hostname-validating and non-validating client contexts, which the raw score does not convey. CWE is listed as N/A and no EPSS/KEV data was supplied, so the automated-exploitability dimension cannot be evaluated from the input.

An application uses the Vert.x HTTP client to make outbound HTTPS calls, with some connections configured to require hostname verification; due to the cache-key collision, one of those requests is served a cached SSL context that silently skips hostname validation. An attacker holding a network man-in-the-middle position (e.g., via DNS/ARP spoofing or a rogue upstream) then presents a mismatched-but-trusted-looking certificate, intercepting and potentially altering the TLS traffic the client believed was validated. No public exploit code is identified at time of analysis, and the high attack complexity (AC:H) reflects the need for both the vulnerable multi-context configuration and the MITM position.