External risk intelligence

ssl_verify_fun Improper Certificate Validation Allows Hostname Impersonation

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-117666

This is a library-level vulnerability in an Erlang TLS verification module. While network-reachable, it only affects specific implementations such as clients that manually disable SNI or servers that use this library to verify client certificates. It is not a standalone public-facing service, and exploitation requires specific, non-default application configurations, making broad public internet exposure uncommon.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in a TLS verification library could allow an attacker to impersonate a trusted server or client. This occurs when the library improperly validates certificates, specifically with partial-label wildcards, potentially misleading systems into accepting a fraudulent identity. The primary concern is confirming if our environment utilizes this specific library in configurations that expose this weakness.

TLS certificate validation flaw.
Protects against impersonation risks.
Confirm library usage and exposure.

Attack Path

How an attacker could exploit the issue

An attacker in the middle can impersonate a TLS peer by using a specially crafted certificate. This occurs when the certificate's wildcard does not adhere to standard hostname matching rules, allowing it to be accepted for a different domain or IP address than intended. This could lead to the TLS peer being impersonated.

Network access required.
Mismatched certificate validation.
Impersonation of TLS peer.

Live Threat

Current exploitation, exposure, and threat context

An attacker could impersonate a TLS peer when certain conditions are met, potentially leading to a security compromise. This could affect clients that disable server name indication (SNI) or servers that rely on this library for client certificate hostname verification.

TLS peer impersonation.
Certificate validation bypass.
Unauthorized access to services.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-world action for this vulnerability likely involves application owners, platform teams, and potentially network security teams responsible for TLS configurations. The initial practical move is to identify all instances of the affected `ssl_verify_fun` library, determine their reachability and business criticality, and then locate the specific owners for remediation planning.

Application and Platform teams own remediation.
Verify TLS configurations and client SNI usage.
Plan for library updates or configuration hardening.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the ssl_verify_fun library?

It is an Erlang/OTP utility library designed to help developers implement hostname verification during TLS handshakes. It provides functions to check if a server's certificate matches the expected hostname, ensuring secure communication. It is frequently integrated into Erlang applications that need fine-grained control over how TLS peer identities are validated.

How does CVE-2026-117666 affect certificate validation?

This vulnerability, classified as CWE-297 (Improper Validation of Certificate with Host Mismatch), occurs when the library mishandles 'partial-label' wildcards. Instead of restricting wildcards to a single domain label as per RFC 6125, the logic incorrectly accepts broader matches. This allows a malicious certificate to be falsely trusted for hostnames or IP addresses it should not be authorized to represent.

Do I need to worry about default TLS connections?

Likely not. The bug does not trigger if Server Name Indication (SNI) is enabled and handled correctly by the underlying Erlang/OTP client, as the library's verification logic is bypassed or superseded in those standard flows. The risk is limited to non-standard implementations, such as clients that explicitly disable SNI or servers configured to use this library for validating client-provided certificates.

Why is this CVE classified as unlikely in Halo Surface Signal?

Halo Surface Signal identifies this as 'Unlikely' because it is a low-level library component rather than a standalone, public-facing service. Exploitation requires an attacker to be positioned in the middle of a network flow while simultaneously targeting specific, non-default application configurations. General internet-facing systems using standard TLS libraries are not inherently exposed.

How should I respond to this threat advisory?

Start by auditing your application codebase to identify where the ssl_verify_fun library is imported and utilized. Once identified, evaluate if those specific modules are configured with SNI disabled or are used for client certificate verification. Prioritize updates for any services identified as using versions 1.0.1 through 1.1.7 of the library to ensure you are running a patched version.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.