CVE-2026-66053
Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift Python bindings. This issue affects Apache Thrift: bef
CVSS
5.9
Medium
EPSS
—
KEV
—
Exploit Today
—
0-100
Published: Jul 27, 2026 · Last modified: Jul 27, 2026 · CWE-297
Not enough EPSS history yet.
Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift Python bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. This replaces CVE-2026-41603
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-48145——
———Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift C++ bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.8hCVE-2026-48144——
———Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift c_glib bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.8hCVE-2026-15243—6.6%
——2Apereo CAS Client accepts any CA-trusted certificate for any hostname, provided the URL the client is calling matches the configured allowlist or regex. An attacker with a MITM position (DNS poisoning, rogue Wi-Fi, malicious proxy, etc.) can provide any CA-signed certificate for a hostname that matches the configured allowlist or regex. This can lead to intercepting the CAS exchange, capturing the Ticket-Granting Ticket (TGT), and subsequently obtaining Service Tickets on behalf of the victim.
Because maintainers contact attempts were unsuccessful, vulnerabilities have only been confirmed in version 4.1.0 (Java Apereo CAS Client) and 3.6.4 (Jasig CAS Client) but may also affect other versions.3dCVE-2026-15925—7.5%
——2Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 and 3.18.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim's connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python versions 4.7.1 and 3.18.1. Users must manually upgrade.11dCVE-2026-443937.4 HIG5.6%
——2An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.5dCVE-2026-355638.5 HIG8.0%
——2It was identified that the LDAP client implementation in version 2.1.7 does not verify if the server certificate matches the intended LDAP
hostname. While the underlying code validates the certificate chain
against a trusted authority, the absence of endpoint identification
allows a valid certificate issued for an entirely unrelated host to be
improperly accepted. This oversight leaves the connection highly
vulnerable to server impersonation and complete connection compromise.
The
root cause of this vulnerability lies in the incomplete TLS server
identity verification within the LDAP client implementation.
The attacker requires MITM capability on the network to exploit this vulnerability. This attacker must be able to present a certificate trusted by the client's configured trust store.
The hostname verification has been enforced in the new version of the LDAP API6d