Total
53 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-8285 | 1 Redhat | 2 Amq Streams, Kroxylicious | 2024-11-13 | 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. | ||||
| CVE-2023-34143 | 3 Hitachi, Linux, Microsoft | 3 Device Manager, Linux Kernel, Windows | 2024-10-21 | 5.6 Medium |
| 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-2024-38324 | 1 Ibm | 2 Storage Defender, Storage Defender Resiliency Service | 2024-09-30 | 5.9 Medium |
| 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-2022-22305 | 1 Fortinet | 4 Fortianalyzer, Fortimanager, Fortios and 1 more | 2024-09-27 | 5.4 Medium |
| 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-2022-29082 | 1 Dell | 1 Emc Networker | 2024-09-16 | 3.7 Low |
| 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-2017-2911 | 1 Meetcircle | 2 Circle With Disney, Circle With Disney Firmware | 2024-09-16 | 5.9 Medium |
| 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-2017-2912 | 1 Meetcircle | 2 Circle With Disney, Circle With Disney Firmware | 2024-09-16 | 5.9 Medium |
| 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-2022-32153 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2024-09-16 | 8.1 High |
| 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-2024-7346 | 1 Progress | 1 Openedge | 2024-09-05 | 7.2 High |
| 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-2466 | 1 Redhat | 1 Jboss Core Services | 2024-08-23 | 6.5 Medium |
| 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-2024-37015 | 1 Adacore | 1 Ada Web Services | 2024-08-14 | 7.4 High |
| 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-2008-1676 | 2 Netscape, Redhat | 2 Certificate Management System, Certificate System | 2024-08-07 | N/A |
| Red Hat PKI Common Framework (rhpki-common) in Red Hat Certificate System (aka Certificate Server or RHCS) 7.1 through 7.3, and Netscape Certificate Management System 6.x, does not recognize Certificate Authority profile constraints on Extensions, which might allow remote attackers to bypass intended restrictions and conduct man-in-the-middle attacks by submitting a certificate signing request (CSR) and using the resulting certificate. | ||||
| CVE-2009-3766 | 2 Mutt, Openssl | 2 Mutt, Openssl | 2024-08-07 | N/A |
| mutt_ssl.c in mutt 1.5.16 and other versions before 1.5.19, when OpenSSL is used, does not verify the domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. | ||||
| CVE-2012-6153 | 2 Apache, Redhat | 13 Commons-httpclient, Developer Toolset, Jboss Bpms and 10 more | 2024-08-06 | N/A |
| http/conn/ssl/AbstractVerifier.java in Apache Commons HttpClient before 4.2.3 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field. NOTE: this issue exists because of an incomplete fix for CVE-2012-5783. | ||||
| CVE-2013-7449 | 3 Canonical, Hexchat Project, Xchat | 4 Ubuntu Linux, Hexchat, Xchat and 1 more | 2024-08-06 | N/A |
| The ssl_do_connect function in common/server.c in HexChat before 2.10.2, XChat, and XChat-GNOME does not verify that the server hostname matches a domain name in the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. | ||||
| CVE-2013-7398 | 2 Async-http-client Project, Redhat | 5 Async-http-client, Jboss Bpms, Jboss Brms and 2 more | 2024-08-06 | N/A |
| main/java/com/ning/http/client/AsyncHttpClientConfig.java in Async Http Client (aka AHC or async-http-client) before 1.9.0 does not require a hostname match during verification of X.509 certificates, which allows man-in-the-middle attackers to spoof HTTPS servers via an arbitrary valid certificate. | ||||
| CVE-2013-6444 | 1 Pywbem Project | 1 Pywbem | 2024-08-06 | N/A |
| PyWBEM 0.7 and earlier does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. | ||||
| CVE-2014-8167 | 1 Redhat | 3 Enterprise Virtualization, Vdsclient, Virtual Desktop Server Manager | 2024-08-06 | 5.9 Medium |
| vdsm and vdsclient does not validate certficate hostname from another vdsm which could facilitate a man-in-the-middle attack | ||||
| CVE-2014-3604 | 2 Not Yet Commons Ssl Project, Redhat | 2 Not Yet Commons Ssl, Jboss Enterprise Soa Platform | 2024-08-06 | N/A |
| Certificates.java in Not Yet Commons SSL before 0.3.15 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. | ||||
| CVE-2014-3596 | 2 Apache, Redhat | 3 Axis, Enterprise Linux, Jboss Enterprise Portal Platform | 2024-08-06 | N/A |
| The getCN function in Apache Axis 1.4 and earlier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field. NOTE: this issue exists because of an incomplete fix for CVE-2012-5784. | ||||