A TCP client can initiate a TLS handshake and supply a server name extension that matches any value accepted by a server’s wildcard certificate. The server therefore accepts connections based on the wildcard, even if the client presents a host name that is not otherwise authorized. In effect, this allows a malicious or misconfigured client to gain TLS connectivity to the server under any arbitrary subdomain, potentially bypassing Server Name Indication (SNI) checks and creating a surface for host‑name spoofing, interception or unauthorized routing of traffic. The core weakness is that the server accepts any subdomain that fits the wildcard pattern without performing stricter validation of the presented host name, which can subvert standard TLS hostname verification.

Eclipse Vert.x

The CVSS score of 6.9 indicates a moderate severity. The EPSS score of < 1% indicates a very low likelihood of exploitation, and the vulnerability is not listed in the CISA KEV catalog. An attacker must be able to open a TCP connection to the target server, so the attack vector is primarily network‑based. Once the client can present any subdomain accepted by the wildcard certificate, the attacker may impersonate legitimate hosts or facilitate man‑in‑the‑middle scenarios within applications that rely on SNI for routing or security checks. The exploit is straightforward and could be automated, but its impact depends on how tightly the server uses the presented hostname for access control or routing decisions.