Overview 80 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
80matches
0in Waratek scope0.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
0
0.0%
Not applicable
80
100.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
80
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
10
12.5%
Forecast only
0
0.0%
No public exploit
70
87.5%
split by
peak 45 / year
20141
Not applicable1
Medium1
not blocked1
No public exploit1
20150
20161
Not applicable1
Medium1
not blocked1
No public exploit1
20172
Not applicable2
Medium2
not blocked2
No public exploit2
20180
20190
20202
Not applicable2
Critical1
Medium1
not blocked2
No public exploit2
20214
Not applicable4
Critical1
High2
Medium1
not blocked4
No public exploit4
20222
Not applicable2
High1
Medium1
not blocked2
No public exploit2
20238
Not applicable8
High3
Medium5
not blocked8
No public exploit8
20246
Not applicable6
High3
Medium3
not blocked6
Proof of concept only1
No public exploit5
20259
Not applicable9
Critical1
High4
Medium4
not blocked9
Proof of concept only1
No public exploit8
202645
Not applicable45
Critical9
High19
Medium15
Low2
not blocked45
Proof of concept only8
No public exploit37
2014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-129118 | High | 2026-11-13 | Not applicable | No public exploit | C-Kermit 8.0.200 before 11.1.515 contains an improper certificate hostname validation vulnerability that allows attackers to impersonate hosts by abusing wildcard matching in dNSName_cmp() in ck_ssl.c. Attackers holding a trusted certificate with over-matching names containing asterisks, question marks, brackets, or empty labels can intercept credentials and data over Telnet, FTP, and HTTP TLS connections. |
| CVE-2026-129117 | High | 2026-11-13 | Not applicable | No public exploit | C-Kermit 8.0.200 before 11.1.515 contains an improper certificate validation vulnerability that allows machine-in-the-middle attackers to impersonate Telnet servers because ssl_reply() never calls ssl_check_server_name(). Attackers can refuse START-TLS, offer Telnet AUTHENTICATION SSL, and present any trusted CA certificate to capture user credentials and session data. |
| CVE-2026-123848 | High | 2026-11-06 | Not applicable | No public exploit | In JetBrains IntelliJ IDEA before 2026.3 host name verification was missing for server TLS certificates |
| CVE-2026-112339 | High | 2026-11-06 | Not applicable | Proof of concept only | Wazuh from 3.9.0 before 4.14.9 contains a missing TLS hostname verification vulnerability in the fluent-forward module's wm_fluent_ssl_ctx() that allows network attackers to impersonate the Fluentd collector by presenting any certificate chaining to the configured ca_file. Attackers who redirect the connection via DNS, ARP, or on-path positions can receive forwarded security telemetry and the shared_key_hexdigest for offline cracking. |
| CVE-2026-115758 | High | 2026-11-04 | Not applicable | No public exploit | SumatraPDF is a multi-format reader for Windows. In version 3.6.1 and earlier, HttpGet() in src/base/Http_win.cpp unconditionally passes INTERNET_FLAG_IGNORE_CERT_CN_INVALID to WinINet, disabling hostname matching for HTTPS update metadata and crash-symbol requests while retaining certificate-chain validation. A network-positioned attacker with a Windows-trusted certificate for an attacker-controlled domain can impersonate the project's update host, inject promo text and a clickable URL before update metadata validation, and provide an attacker-controlled archive to ExtractSymbols(). Installer replacement is not directly possible because HttpGetToFile() validates TLS and MaybeStartUpdateDownload() restricts the download host. No fixed version is available as of this review. |
| CVE-2026-117666 | Critical | 2026-10-30 | Not applicable | No public exploit | 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. |
| CVE-2026-66392 | Medium | 2026-10-21 | Not applicable | No public exploit | Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint. Affected Scenarios: Applications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint. How to Fix: Upgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from https://github.com/apache/brpc/pull/3408 . Note: The new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected. |
| CVE-2026-86410 | High | 2026-10-20 | Not applicable | Proof of concept only | A flaw in the curl command line tool's logic makes it only set SSH host verification options when interacting directly using SFTP or SCP, and not as a result of following a redirect. |
| CVE-2026-85974 | High | 2026-10-12 | Not applicable | No public exploit | Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not consistently validate TLS certificate hostnames for certain outbound connections. A network-positioned attacker could exploit this weakness to intercept or modify communications with an affected service. |
| CVE-2026-107819 | Medium | 2026-10-09 | Not applicable | No public exploit | MariaDB Connector/C is a C and C++ client library for connecting applications to MariaDB and MySQL databases. From 3.4.1 until 3.4.10, the MariaDB Connector/C libmariadb Zero-Configuration SSL authentication-switch logic checked certificate trust failure but did not reject a TLS hostname verification mismatch before selecting a non-hashing authentication plugin. An active man-in-the-middle attacker with a valid certificate for another hostname could request mysql_clear_password and obtain the database password inside the attacker-controlled TLS connection. Other MariaDB connectors are not affected. This issue is fixed in version 3.4.10. |
| CVE-2026-88647 | Medium | 2026-10-08 | Not applicable | No public exploit | GnuTLS v3.8.13 can perhaps unexpectedly trust a certificate on the basis of Common Name when Subject Alternative Name has an SRV otherName (1.3.6.1.5.5.7.8.7) whose value is an OCTET STRING. NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy. |
| CVE-2026-107660 | Medium | 2026-10-08 | Not applicable | No public exploit | FFmpeg before 8.1.3 and 9.x before 9.0.2 contains an improper certificate validation vulnerability in tls_open() of libavformat/tls_mbedtls.c, which skips hostname checks for IP-address hosts. Network attackers can intercept https, rtmps, or tls connections to IP-literal URLs with any trusted CA-issued certificate to read and tamper with streams. |
| CVE-2026-85088 | Medium | 2026-10-02 | Not applicable | No public exploit | Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the accessManager property does so in D — which compares the peer certificate against the host name that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a "skip" result rather than a rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection to the second name. Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client's trust store and whose Common Name matches the connected host name. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0. |
| CVE-2026-102669 | Medium | 2026-10-01 | Not applicable | No public exploit | Joyland AI app does not verify hostnames, allowing a malicious host to connect or intercept chat messages. |
| CVE-2026-19553 | High | 2026-09-30 | Not applicable | No public exploit | ssl.SSLContext.wrap_bio() didn't require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isn't supplied then hostname verification would be silently skipped. This defect could lead to programs where certificate hostname verification *appeared* to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration. If the program passes a server_hostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability. Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isn't supplied. |
| CVE-2026-91769 | Medium | 2026-09-25 | Not applicable | No public exploit | PHP's OpenSSL stream peer verification checks the certificate's subjectAltName entries first and, whenever no entry matches, falls back to the Common Name. RFC 6125 requires the CN to be ignored once the certificate presents any service identity, so a certificate carrying a non-matching DNS SAN was still accepted when its CN matched the requested peer_name. A certificate trusted by the client for one name can therefore be used to impersonate another. |
| CVE-2026-63374 | Critical | 2026-09-22 | Not applicable | No public exploit | AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. Prior to 4.14.2, connect_tcp() and TLSStream.wrap() can validate internationalized host names after the standard library converts them with IDNA 2003 instead of IDNA 2008. When a connection to a non-ASCII domain is hijacked or redirected, an attacker can obtain a legitimate certificate for the different ASCII hostname produced by IDNA 2003 and present it to the client, causing the malicious endpoint's certificate to validate. This issue is fixed in version 4.14.2. |
| CVE-2026-91166 | Medium | 2026-09-21 | Not applicable | Proof of concept only | Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. From 0.25.0 until 0.27.6, the browser SSH path in warpgate-web-ssh/src/manager.rs handles RCEvent::HostKeyUnknown without the presenting hop identity and instead passes ssh_options.host and ssh_options.port for the final target to KnownHosts::trust. In Prompt and AutoAccept modes, a jump host key can therefore be stored for the target address. A machine later presenting the jump host key at the target address can be accepted as the target, allowing interception of user traffic and a newly issued certificate when certificate authentication is used. The native SSH path is unaffected because it tracks each hop separately. This issue is fixed in version 0.27.6. |
| CVE-2026-84975 | High | 2026-09-18 | Not applicable | No public exploit | PJSIP is a free and open source multimedia communication library written in C. In 2.17 and earlier, the OpenSSL and GnuTLS backends in pjlib/src/pj/ssl_sock_ossl.c and pjlib/src/pj/ssl_sock_gtls.c copy DNS SubjectAltName values with string functions that recalculate their length and truncate an embedded NUL byte. With server verification enabled through --tls-verify-server for the PJSIP TLS/SIPS transport, a certificate containing a DNS SubjectAltName formed from the target hostname prefix followed by an embedded NUL and an attacker-controlled suffix can therefore be accepted for the prefix hostname. An attacker who possesses such a certificate from a trusted issuer and can intercept the connection can impersonate the target server, complete the SIP session, and receive REGISTER credentials. The mbedTLS backend is not affected because it preserves the explicit string length. No fixed version is available as of this review. |
| CVE-2026-92943 | Critical | 2026-09-17 | Not applicable | No public exploit | Improper validation of certificate with host mismatch in the MQTT client TLS connection layer in AWS IoT Device SDK for Python 1.5.3 through 1.6.0 on Python 3.7 and later might allow an adversary-in-the-middle actor to impersonate the AWS IoT Core endpoint, read device telemetry, and inject arbitrary MQTT messages that the device processes as authentic, via a certificate issued for an unrelated hostname by a certificate authority present in the device trust store. To remediate this issue, users should upgrade to version 1.6.1. |
| CVE-2026-79636 | High | 2026-09-09 | Not applicable | No public exploit | Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Validation of Certificate with Host Mismatch vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. |
| CVE-2026-84393 | High | 2026-09-08 | Not applicable | No public exploit | A improper validation of certificate with host mismatch vulnerability in Fortinet FortiOS 7.6.1 through 7.6.6, FortiProxy 7.6.2 through 7.6.6 may allow attacker to information disclosure via <insert attack vector here> |
| CVE-2026-84197 | Critical | 2026-09-08 | Not applicable | No public exploit | In Eclipse Ditto's Node.js JavaScript client, all released versions of @eclipse-ditto/ditto-javascript-client-node from 2.0.0 to 3.9.0 and of its predecessor package @eclipse-ditto/ditto-javascript-client-node_1.0 from 1.0.0 to 2.1.0, the WebSocket transport hard-codes rejectUnauthorized: false when creating the underlying ws WebSocket. Certificate chain and hostname validation are therefore disabled for every wss:// connection, and no builder option, constructor argument or environment variable lets an application turn validation back on. An attacker in a position to intercept the connection can present an arbitrary certificate, complete the TLS handshake, read the credentials that the configured authentication provider sends in the Authorization header of the WebSocket upgrade request, and read, alter or inject Ditto Protocol messages for the lifetime of the connection. The Java client, the browser/DOM JavaScript client and the HTTP transport of the Node.js client are not affected. |
| CVE-2026-79943 | Medium | 2026-09-07 | Not applicable | No public exploit | Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Validation of Certificate with Host Mismatch vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass. |
| CVE-2026-9744 | Medium | 2026-09-03 | Not applicable | No public exploit | IBM Netezza Software 11.3.0.3 through Interim Fix 002 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques. |
| CVE-2026-53583 | Medium | 2026-08-20 | Not applicable | Proof of concept only | libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Prior to 1.8.6 and 1.9.5, verify_server_cert in src/libgit2/streams/openssl.c uses an inverted !!memcmp result in the GEN_IPADD branch when comparing an IP-literal host with a certificate IP SubjectAltName. OpenSSL builds reject matching IP addresses and accept mismatched IP addresses, allowing a network attacker with a CA-trusted certificate containing any IP SubjectAltName to intercept libgit2 connections to IP-literal HTTPS URLs. DNS SubjectAltName validation and non-OpenSSL TLS backends are not affected. This issue is fixed in versions 1.8.6 and 1.9.5. |
| CVE-2026-49457 | Critical | 2026-08-14 | Not applicable | No public exploit | erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents. |
| CVE-2026-65942 | High | 2026-08-10 | Not applicable | No public exploit | TLS hostname verification issue in Apache Ranger Client Code in versions <= 2.8.0. Users are recommended to upgrade to version 2.9.0, which fixes this issue. |
| CVE-2026-12730 | Low | 2026-08-05 | Not applicable | No public exploit | IBM Business Automation Workflow containers and traditional 26.0.0, 25.0.0 through 25.0.0 Interim Fix 005, 24.0.1 through 24.0.1 Interim Fix 007, and 24.0.0 through 24.0.0 Interim Fix 009 IBM Business Automation Workflow fails to properly verify that the hostname matches the server certificate potentially allowing connections to an attacker-controlled server. |
| CVE-2026-58040 | Medium | 2026-07-30 | Not applicable | No public exploit | An incomplete fix has been identified in Node.js: HTTPS Agent TLS session reuse skips hostname verification across identity policies (incomplete fix of CVE-2026-48934). This vulnerability affects Node.js **22.x**, **24.x**, and **26.x**. |
| CVE-2026-66053 | Medium | 2026-07-27 | Not applicable | No public exploit | 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 |
| CVE-2026-48145 | High | 2026-07-27 | Not applicable | No public exploit | 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. |
| CVE-2026-48144 | Critical | 2026-07-27 | Not applicable | No public exploit | 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. |
| CVE-2026-15243 | High | 2026-07-24 | Not applicable | No public exploit | Apereo 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. |
| CVE-2026-15925 | Critical | 2026-07-16 | Not applicable | No public exploit | Improper 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. |
| CVE-2026-9547 | High | 2026-07-03 | Not applicable | Proof of concept only | When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack. |
| CVE-2026-12064 | High | 2026-07-03 | Not applicable | Proof of concept only | When a user invokes curl using a schemeless URL combined with `--proto-default` sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error. |
| CVE-2026-54275 | Low | 2026-06-22 | Not applicable | No public exploit | AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, the server_hostname TLS SNI check can be bypassed when an existing connection is reused. If an application makes multiple requests to the same domain, but with different per-request server_hostname parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check. This vulnerability is fixed in 3.14.1. |
| CVE-2026-12162 | Medium | 2026-06-16 | Not applicable | No public exploit | Improper host validation in the social login autofill feature in Devolutions Remote Desktop Manager 2026.2.8 allows an attacker to disclose stored social login credentials via a crafted web entry pointing to a provider lookalike domain. |
| CVE-2026-44393 | High | 2026-06-04 | Not applicable | No public exploit | An 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. |
| CVE-2026-42790 | High | 2026-05-27 | Not applicable | No public exploit | Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com): First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName. Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hostname matcher. This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, OTP 27.3.4.12, OTP 28.5.0.1, and OTP 29.0.1, corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1. |
| CVE-2026-44467 | High | 2026-05-13 | Not applicable | No public exploit | The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. From 1.2581.0 to before 1.4304.0, Claude Desktop's SSH remote development feature verified only whether a hostname existed in ~/.ssh/known_hosts without comparing the server's presented host key against the stored key. This allowed a network-positioned attacker to present an arbitrary SSH host key and have the connection silently accepted, enabling a man-in-the-middle attack on remote development sessions. Successful exploitation required the attacker to be in a network position to intercept SSH traffic (e.g., via ARP spoofing, rogue Wi-Fi, or DNS poisoning) and the target hostname to already have an entry in the victim's known_hosts file. This vulnerability is fixed in 1.4304.0. |
| CVE-2026-26214 | Critical | 2026-02-12 | Not applicable | Proof of concept only | Galaxy FDS Android SDK (XiaoMi/galaxy-fds-sdk-android) version 3.0.8 and prior disable TLS hostname verification when HTTPS is enabled (the default configuration). In GalaxyFDSClientImpl.createHttpClient(), the SDK configures Apache HttpClient with SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER, which accepts any valid TLS certificate regardless of hostname mismatch. Because HTTPS is enabled by default in FDSClientConfiguration, all applications using the SDK with default settings are affected. This vulnerability allows a man-in-the-middle attacker to intercept and modify SDK communications to Xiaomi FDS cloud storage endpoints, potentially exposing authentication credentials, file contents, and API responses. The XiaoMi/galaxy-fds-sdk-android open source project has reached end-of-life status. |
| CVE-2025-15079 | Medium | 2026-01-08 | Not applicable | Proof of concept only | When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could still mistakenly accept connecting to hosts *not present* in the specified file if they were added as recognized in the libssh *global* known_hosts file. |
| CVE-2025-68637 | Critical | 2026-01-07 | Not applicable | No public exploit | The Uniffle HTTP client is configured to trust all SSL certificates and disables hostname verification by default. This insecure configuration exposes all REST API communication between the Uniffle CLI/client and the Uniffle Coordinator service to potential Man-in-the-Middle (MITM) attacks. This issue affects all versions from before 0.10.0. Users are recommended to upgrade to version 0.10.0, which fixes the issue. |
| CVE-2025-25253 | High | 2025-10-14 | Not applicable | No public exploit | An Improper Validation of Certificate with Host Mismatch vulnerability [CWE-297] in FortiProxy version 7.6.1 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions and FortiOS version 7.6.2 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions ZTNA proxy may allow an unauthenticated attacker in a man-in-the middle position to intercept and tamper with connections to the ZTNA proxy |
| CVE-2025-46408 | Critical | 2025-09-15 | Not applicable | Proof of concept only | An issue was discovered in the methods push.lite.avtech.com.AvtechLib.GetHttpsResponse and push.lite.avtech.com.Push_HttpService.getNewHttpClient in AVTECH EagleEyes 2.0.0. The methods set ALLOW_ALL_HOSTNAME_VERIFIER, bypassing domain validation. |
| CVE-2024-12925 | High | 2025-09-01 | Not applicable | No public exploit | Improper Validation of Certificate with Host Mismatch vulnerability in Akınsoft QR Menü allows HTTP Response Splitting. This issue affects QR Menü: from s1.05.05 before v1.05.12. |
| CVE-2025-4295 | Medium | 2025-07-22 | Not applicable | No public exploit | Improper Validation of Certificate with Host Mismatch vulnerability in HotelRunner B2B allows HTTP Response Splitting. This issue affects B2B: before 04.06.2025. |
| CVE-2025-49015 | Medium | 2025-06-18 | Not applicable | No public exploit | The Couchbase .NET SDK (client library) before 3.7.1 does not properly enable hostname verification for TLS certificates. In fact, the SDK was also using IP addresses instead of hostnames due to a configuration option that was incorrectly enabled by default. |
| CVE-2024-54019 | Medium | 2025-06-10 | Not applicable | No public exploit | A improper validation of certificate with host mismatch in Fortinet FortiClientWindows version 7.4.0, versions 7.2.0 through 7.2.6, and 7.0 all versions allow an unauthorized attacker to redirect VPN connections via DNS spoofing or another form of redirection. |
| CVE-2025-42921 | Medium | 2025-04-17 | Not applicable | No public exploit | In JetBrains Toolbox App before 2.6 host key verification was missing in SSH plugin |
| CVE-2025-2190 | High | 2025-03-11 | Not applicable | No public exploit | The mobile application (com.transsnet.store) has a man-in-the-middle attack vulnerability, which may lead to code injection risks. |
| CVE-2024-49782 | High | 2025-02-20 | Not applicable | No public exploit | IBM OpenPages with Watson 8.3 and 9.0 could allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery. |
| CVE-2024-38324 | Medium | 2024-09-25 | Not applicable | No public exploit | IBM Storage Defender 2.0.0 through 2.0.7 on-prem defender-sensor-cmd CLI does not validate server name during registration and unregistration operations which could expose sensitive information to an attacker with access to the system. |
| CVE-2024-7346 | High | 2024-09-03 | Not applicable | No public exploit | Host name validation for TLS certificates is bypassed when the installed OpenEdge default certificates are used to perform the TLS handshake for a networked connection. This has been corrected so that default certificates are no longer capable of overriding host name validation and will need to be replaced where full TLS certificate validation is needed for network security. The existing certificates should be replaced with CA-signed certificates from a recognized certificate authority that contain the necessary information to support host name validation. |
| CVE-2024-37015 | High | 2024-08-13 | Not applicable | No public exploit | An issue was discovered in Ada Web Server 20.0. When configured to use SSL (which is not the default setting), the SSL/TLS used to establish connections to external services is done without proper hostname validation. This is exploitable by man-in-the-middle attackers. |
| CVE-2024-2462 | Medium | 2024-06-11 | Not applicable | No public exploit | Allow attackers to intercept or falsify data exchanges between the client and the server |
| CVE-2024-32868 | High | 2024-04-26 | Not applicable | No public exploit | ZITADEL provides users the possibility to use Time-based One-Time-Password (TOTP) and One-Time-Password (OTP) through SMS and Email. While ZITADEL already gives administrators the option to define a `Lockout Policy` with a maximum amount of failed password check attempts, there was no such mechanism for (T)OTP checks. This issue has been patched in version 2.50.0. |
| CVE-2024-2466 | Medium | 2024-03-27 | Not applicable | Proof of concept only | libcurl did not check the server certificate of TLS connections done to a host specified as an IP address, when built to use mbedTLS. libcurl would wrongly avoid using the set hostname function when the specified hostname was given as an IP address, therefore completely skipping the certificate check. This affects all uses of TLS protocols (HTTPS, FTPS, IMAPS, POPS3, SMTPS, etc). |
| CVE-2023-5909 | High | 2023-11-30 | Not applicable | No public exploit | KEPServerEX does not properly validate certificates from clients which may allow unauthenticated users to connect. |
| CVE-2022-22305 | Medium | 2023-09-01 | Not applicable | No public exploit | An improper certificate validation vulnerability [CWE-295] in FortiManager 7.0.1 and below, 6.4.6 and below; FortiAnalyzer 7.0.2 and below, 6.4.7 and below; FortiOS 6.2.x and 6.0.x; FortiSandbox 4.0.x, 3.2.x and 3.1.x may allow a network adjacent and unauthenticated attacker to man-in-the-middle the communication between the listed products and some external peers. |
| CVE-2023-34143 | High | 2023-07-18 | Not applicable | No public exploit | Improper Validation of Certificate with Host Mismatch vulnerability in Hitachi Device Manager on Windows, Linux (Device Manager Server, Device Manager Agent, Host Data Collector components) allows Man in the Middle Attack.This issue affects Hitachi Device Manager: before 8.8.5-02. |
| CVE-2023-24568 | Medium | 2023-05-30 | Not applicable | No public exploit | Dell NetWorker, contains an Improper Validation of Certificate with Host Mismatch vulnerability in Rabbitmq port which could disallow replacing CA signed certificates. |
| CVE-2022-48308 | Medium | 2023-02-16 | Not applicable | No public exploit | It was discovered that the sls-logging was not verifying hostnames in TLS certificates due to a misuse of the javax.net.ssl.SSLSocketFactory API. A malicious attacker in a privileged network position could abuse this to perform a man-in-the-middle attack. A successful man-in-the-middle attack would allow them to intercept, read, or modify network communications to and from the affected service. |
| CVE-2022-48307 | Medium | 2023-02-16 | Not applicable | No public exploit | It was discovered that the Magritte-ftp was not verifying hostnames in TLS certificates due to a misuse of the javax.net.ssl.SSLSocketFactory API. A malicious attacker in a privileged network position could abuse this to perform a man-in-the-middle attack. A successful man-in-the-middle attack would allow them to intercept, read, or modify network communications to and from the affected service. In the case of a successful man in the middle attack on magritte-ftp, an attacker would be able to read and modify network traffic such as authentication tokens or raw data entering a Palantir Foundry stack. |
| CVE-2022-48306 | Medium | 2023-02-16 | Not applicable | No public exploit | Improper Validation of Certificate with Host Mismatch vulnerability in Gotham Chat IRC helper of Palantir Gotham allows A malicious attacker in a privileged network position could abuse this to perform a man-in-the-middle attack. A successful man-in-the-middle attack would allow them to intercept, read, or modify network communications to and from the affected service. This issue affects: Palantir Palantir Gotham Chat IRC helper versions prior to 30221005.210011.9242. |
| CVE-2022-27890 | High | 2023-02-16 | Not applicable | No public exploit | It was discovered that the sls-logging was not verifying hostnames in TLS certificates due to a misuse of the javax.net.ssl.SSLSocketFactory API. A malicious attacker in a privileged network position could abuse this to perform a man-in-the-middle attack. A successful man-in-the-middle attack would allow them to intercept, read, or modify network communications to and from the affected service. In the case of AtlasDB, the vulnerability was mitigated by other network controls such as two-way TLS when deployed as part of a Palantir platform. Palantir still recommends upgrading to a non-vulnerable version out of an abundance of caution. |
| CVE-2022-32153 | High | 2022-06-15 | Not applicable | No public exploit | Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation. |
| CVE-2022-29082 | Medium | 2022-05-26 | Not applicable | No public exploit | Dell EMC NetWorker versions 19.1.x, 19.1.0.x, 19.1.1.x, 19.2.x, 19.2.0.x, 19.2.1.x 19.3.x, 19.3.0.x, 19.4.x, 19.4.0.x, 19.5.x,19.5.0.x, 19.6 and 19.6.0.1 and 19.6.0.2 contain an Improper Validation of Certificate with Host Mismatch vulnerability in Rabbitmq port 5671 which could allow remote attackers to spoof certificates. |
| CVE-2021-33695 | Critical | 2021-09-15 | Not applicable | No public exploit | Potentially, SAP Cloud Connector, version - 2.0 communication with the backend is accepted without sufficient validation of the certificate. |
| CVE-2020-14387 | High | 2021-05-27 | Not applicable | No public exploit | A flaw was found in rsync in versions since 3.2.0pre1. Rsync improperly validates certificate with host mismatch vulnerability. A remote, unauthenticated attacker could exploit the flaw by performing a man-in-the-middle attack using a valid certificate for another hostname which could compromise confidentiality and integrity of data transmitted using rsync-ssl. The highest threat from this vulnerability is to data confidentiality and integrity. This flaw affects rsync versions before 3.2.4. |
| CVE-2021-21385 | High | 2021-03-24 | Not applicable | No public exploit | Mifos-Mobile Android Application for MifosX is an Android Application built on top of the MifosX Self-Service platform. Mifos-Mobile before commit e505f62 disables HTTPS hostname verification of its HTTP client. Additionally it accepted any self-signed certificate as valid. Hostname verification is an important part when using HTTPS to ensure that the presented certificate is valid for the host. Disabling it can allow for man-in-the-middle attacks. Accepting any certificate, even self-signed ones allows man-in-the-middle attacks. This problem is fixed in mifos-mobile commit e505f62. |
| CVE-2020-15260 | Medium | 2021-03-10 | Not applicable | No public exploit | PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In version 2.10 and earlier, PJSIP transport can be reused if they have the same IP address + port + protocol. However, this is insufficient for secure transport since it lacks remote hostname authentication. Suppose we have created a TLS connection to `sip.foo.com`, which has an IP address `100.1.1.1`. If we want to create a TLS connection to another hostname, say `sip.bar.com`, which has the same IP address, then it will reuse that existing connection, even though `100.1.1.1` does not have certificate to authenticate as `sip.bar.com`. The vulnerability allows for an insecure interaction without user awareness. It affects users who need access to connections to different destinations that translate to the same address, and allows man-in-the-middle attack if attacker can route a connection to another destination such as in the case of DNS spoofing. |
| CVE-2018-19946 | Medium | 2020-09-11 | Not applicable | No public exploit | The vulnerability have been reported to affect earlier versions of Helpdesk. If exploited, this improper certificate validation vulnerability could allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. QNAP has already fixed the issue in Helpdesk 3.0.3 and later. |
| CVE-2020-1887 | Critical | 2020-03-13 | Not applicable | No public exploit | Incorrect validation of the TLS SNI hostname in osquery versions after 2.9.0 and before 4.2.0 could allow an attacker to MITM osquery traffic in the absence of a configured root chain of trust. |
| CVE-2017-2912 | Medium | 2017-11-07 | Not applicable | No public exploit | An exploitable vulnerability exists in the remote control functionality of Circle with Disney running firmware 2.0.1. SSL certificates for specific domain names can cause the goclient daemon to accept a different certificate than intended. An attacker can host an HTTPS server with this certificate to trigger this vulnerability. |
| CVE-2017-2911 | Medium | 2017-11-07 | Not applicable | No public exploit | An exploitable vulnerability exists in the remote control functionality of Circle with Disney running firmware 2.0.1. SSL certificates for specific domain names can cause the rclient daemon to accept a different certificate than intended. An attacker can host an HTTPS server with this certificate to trigger this vulnerability. |
| CVE-2016-1280 | Medium | 2016-09-09 | Not applicable | No public exploit | PKId in Juniper Junos OS before 12.1X44-D52, 12.1X46 before 12.1X46-D37, 12.1X47 before 12.1X47-D30, 12.3 before 12.3R12, 12.3X48 before 12.3X48-D20, 13.3 before 13.3R10, 14.1 before 14.1R8, 14.1X53 before 14.1X53-D40, 14.2 before 14.2R7, 15.1 before 15.1R4, 15.1X49 before 15.1X49-D20, 15.1X53 before 15.1X53-D60, and 16.1 before 16.1R1 allow remote attackers to bypass an intended certificate validation mechanism via a self-signed certificate with an Issuer name that matches a valid CA certificate enrolled in Junos. |
| CVE-2014-3522 | Medium | 2014-08-19 | Not applicable | No public exploit | The Serf RA layer in Apache Subversion 1.4.0 through 1.7.x before 1.7.18 and 1.8.x before 1.8.10 does not properly handle wildcards in the Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof servers via a crafted certificate. |