CVE-2026-102476 in Vert.x
Summary
by MITRE • 10/14/2026
In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP client relies on an SSL context for efficiency purpose, the key of this cache should reflect entirely the SSL semantics of the desired SSL properties. It is possible for a client to ask for an SSL context and obtain an SSL context with weaker properties, for instance a context with hostname validation and obtain a context ignoring hostname validation.
The impacted component is io.vertx:vertx-core.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
Eclipse Vert.x versions ranging from 5.0.0 through 5.12, as well as the specific range of 5.1.0 to 5.9 and version 5.2.0, contain a critical flaw within its HTTP client implementation regarding SSL context caching efficiency. The vulnerability stems from an incorrect key generation mechanism used for storing and retrieving cached Secure Sockets Layer contexts. In these versions, the Vert.x HTTP client utilizes a cache to optimize performance by reusing established SSL sessions rather than performing full handshakes repeatedly. However, the logic determining whether two sets of SSL properties are identical is flawed because it does not account for all semantic aspects of the requested configuration. Specifically, the key used to identify an existing cached context fails to fully reflect the complete set of desired SSL properties, leading to a mismatch between what was explicitly requested and what is actually retrieved from the cache.
The operational impact of this flaw is significant as it allows a client application to request an SSL context with strict security requirements, such as hostname validation enabled, but receive back a cached context that has weaker or different properties, specifically one where hostname validation is disabled. This discrepancy occurs because the caching mechanism incorrectly assumes equivalence between two distinct configurations if their primary identifiers match, ignoring critical differences in security parameters like host name verification settings. Consequently, applications relying on this client to enforce strict TLS policies may inadvertently establish connections without verifying the server's identity against its certificate, effectively bypassing a fundamental defense-in-depth measure designed to prevent man-in-the-middle attacks.
This vulnerability aligns with Common Weakness Enumeration category CWE-295, which describes Improper Certificate Validation, as well as aspects of CWE-674 regarding Uncontrolled Recursion or Resource Consumption if the caching logic leads to unexpected state issues, though the primary concern is the bypassing of security controls. From an ATT&CK perspective, this flaw facilitates techniques associated with MitM under MITRE ATT&CK ID T1557, as attackers could potentially exploit misconfigured SSL contexts to intercept and decrypt traffic that was assumed to be securely authenticated by hostname verification. The failure to validate hostnames means that even if the certificate itself is valid for a different domain, the connection might still proceed without raising an alert in applications that rely on Vert.x's default behavior rather than implementing additional manual checks.
To mitigate this risk, organizations using affected versions of Eclipse Vert.x must upgrade immediately to patched releases where the SSL context caching key generation has been corrected to include all relevant security properties, ensuring that hostname validation settings are properly considered when determining cache hits. Until an upgrade is possible, developers should consider disabling SSL context caching entirely by configuring the HTTP client to not reuse contexts, thereby forcing a full handshake for every connection and ensuring that each session is established with the exact parameters specified in the code. Additionally, implementing explicit hostname verification logic at the application layer can provide a secondary safeguard against this specific class of configuration mismatch errors.