ssl_verify_fun CVE-2026-117666

Requires three things together: (1) an attacker-held leaf certificate whose subjectAltName carries a partial-label wildcard such as f*.example.net (or *.168.1.1 for the IP-literal variant), issued by a CA the victim trusts - the CA/Browser Forum Baseline Requirements disallow such certificates, so realistically this means a private/internal PKI; (2) an adversary-in-the-middle position on the TLS connection; and (3) a deployment where ssl_verify_fun performs the sole hostname check. The last condition holds only when the client sets {server_name_indication, disable}, when a TLS server uses ssl_verify_hostname:verify_fun/3 to verify client-certificate hostnames, when code calls ssl_verify_hostname:verify_cert_hostname/2 directly, or when running Erlang/OTP older than 20.0. LIMITING FACTORS: on Erlang/OTP 20.0 and later with server_name_indication set to a hostname (or an IP from a socket upgrade), the ssl layer runs public_key:pkix_verify_hostname and rejects the mismatch with hostname_check_failed before the user verify_fun sees valid_peer, so default SNI-enabled clients are not exploitable. Whole-label wildcards (*.example.net) are matched correctly and are not affected. The documented workaround on OTP 21+ is to keep SNI set and pass {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]}; hackney and tls_certificate_check already set both options.

The signals pull in opposite directions and must be weighed carefully. The input assigns CVSS 4.0 9.1 (Critical) and vuln.today labels this act_now, yet the concrete exploitation path is tightly constrained. The 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) already encodes this tension: network-reachable and unauthenticated, but high complexity with an attack requirement (AT:P), reflecting that the attacker must hold a certificate carrying a partial-label wildcard issued by a CA the victim trusts. The advisory states the CA/Browser Forum Baseline Requirements forbid such certificates, so realistic exposure is confined to private PKI, and exploitation only matters where ssl_verify_fun is the sole hostname check - specifically {server_name_indication, disable}, TLS servers verifying client-certificate hostnames, direct callers of verify_cert_hostname/2, or Erlang/OTP older than 20.0. On OTP 20.0+ with SNI set to a hostname, the ssl layer rejects the mismatch before the library runs, neutralizing the flaw. No KEV listing and no EPSS score are present in the input, so there is no evidence of active or widespread exploitation; status is no public exploit identified as confirmed working code, though the advisory publishes a step-by-step PoC procedure. Net: this is a genuine authentication-bypass/MITM defect that warrants prompt patching per the act_now label, but its real-world blast radius is narrow (private-PKI, non-default-configuration deployments) rather than broad internet-wide risk - the high score reflects impact severity, not ease or breadth of exploitation.

An adversary who can position themselves in the network path (adversary-in-the-middle) and who possesses a certificate for an identifier like f*.example.net issued by a CA the victim trusts presents it to a client that relies solely on ssl_verify_fun for hostname verification (e.g. with SNI disabled). The library accepts the certificate for f.evil.example.net because the partial-label wildcard is allowed to consume dots across a label boundary, letting the attacker impersonate the host and read or alter the TLS traffic. A detailed PoC procedure (issuing the leaf cert via public_key:pkix_test_data and calling verify_cert_hostname/2) is published in the GHSA advisory, but it is not verified as packaged working exploit code; the high CVSS complexity (AC:H/AT:P) reflects the need for the attacker-held trusted wildcard certificate and a vulnerable non-default configuration.