Total
93 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-79943 | 1 Dell | 1 Secure Connect Gateway | 2026-09-16 | N/A | 4.8 MEDIUM |
| 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-9547 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 7.4 HIGH |
| 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 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 7.5 HIGH |
| 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-9744 | 1 Ibm | 1 Netezza Performance Server | 2026-09-10 | N/A | 5.3 MEDIUM |
| 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-84197 | 2026-09-09 | N/A | N/A | ||
| 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-79636 | 1 Dell | 1 Secure Connect Gateway | 2026-09-09 | N/A | 7.0 HIGH |
| 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-15243 | 2026-09-03 | N/A | N/A | ||
| 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-59272 | 1 Vmware | 1 Spring Advanced Message Queuing Protocol | 2026-09-01 | N/A | 6.8 MEDIUM |
| Any application shipping logs to RabbitMQ over TLS via the Log4j2 appender, relying on the documented default, is exposed to man-in-the-middle interception of every log event. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier | |||||
| CVE-2026-59638 | 1 Bouncycastle | 3 Bc-java, Bctls-fips, Bouncy Castle For Java Lts | 2026-08-28 | N/A | 6.5 MEDIUM |
| In Bouncy Castle for Java before 1.85, JSSE hostname verifier CN-fallback enabled by default despite documented opt-in. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bctls-fips 1.0.24 (1.0.X series), 2.0.24 (2.0.X series) and 2.1.24 (2.1.X series). | |||||
| CVE-2026-44393 | 2026-08-27 | N/A | 7.4 HIGH | ||
| 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-2025-59060 | 1 Apache | 1 Ranger | 2026-08-24 | N/A | 5.3 MEDIUM |
| Hostname verification bypass issue in Apache Ranger NiFiRegistryClient is reported in Apache Ranger versions <= 2.7.0. Users are recommended to upgrade to version 2.8.0, which fixes this issue. | |||||
| CVE-2026-35563 | 1 Apache | 1 Directory Ldap Api | 2026-07-22 | N/A | 8.5 HIGH |
| It 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 API | |||||
| CVE-2026-26214 | 2026-07-14 | N/A | 7.4 HIGH | ||
| 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-68161 | 1 Apache | 1 Log4j | 2026-06-17 | N/A | 4.8 MEDIUM |
| The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. | |||||
| CVE-2025-4295 | 2026-06-17 | N/A | 4.6 MEDIUM | ||
| 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 | 1 Couchbase | 1 .net Sdk | 2026-06-17 | N/A | 4.9 MEDIUM |
| 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-2025-46408 | 1 Avtech | 1 Eagleeyes\(lite\) | 2026-06-17 | N/A | 9.8 CRITICAL |
| 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-2025-42921 | 1 Jetbrains | 1 Toolbox | 2026-06-17 | N/A | 4.2 MEDIUM |
| In JetBrains Toolbox App before 2.6 host key verification was missing in SSH plugin | |||||
| CVE-2025-2190 | 1 Tecno | 1 Com.transsnet.store | 2026-06-17 | N/A | 8.1 HIGH |
| The mobile application (com.transsnet.store) has a man-in-the-middle attack vulnerability, which may lead to code injection risks. | |||||
| CVE-2024-8285 | 1 Redhat | 1 Kroxylicious | 2026-06-17 | N/A | 5.9 MEDIUM |
| A flaw was found in Kroxylicious. When establishing the connection with the upstream Kafka server using a TLS secured connection, Kroxylicious fails to properly verify the server's hostname, resulting in an insecure connection. For a successful attack to be performed, the attacker needs to perform a Man-in-the-Middle attack or compromise any external systems, such as DNS or network routing configuration. This issue is considered a high complexity attack, with additional high privileges required, as the attack would need access to the Kroxylicious configuration or a peer system. The result of a successful attack impacts both data integrity and confidentiality. | |||||