Total
1166 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2020-15732 | 1 Bitdefender | 3 Antivirus Plus, Internet Security, Total Security | 2024-11-21 | 6.5 Medium |
| Improper Certificate Validation vulnerability in the Online Threat Prevention module as used in Bitdefender Total Security allows an attacker to potentially bypass HTTP Strict Transport Security (HSTS) checks. This issue affects: Bitdefender Total Security versions prior to 25.0.7.29. Bitdefender Internet Security versions prior to 25.0.7.29. Bitdefender Antivirus Plus versions prior to 25.0.7.29. | ||||
| CVE-2020-15720 | 2 Dogtagpki, Redhat | 2 Dogtagpki, Enterprise Linux | 2024-11-21 | 6.8 Medium |
| In Dogtag PKI through 10.8.3, the pki.client.PKIConnection class did not enable python-requests certificate validation. Since the verify parameter was hard-coded in all request functions, it was not possible to override the setting. As a result, tools making use of this class, such as the pki-server command, may have been vulnerable to Person-in-the-Middle attacks in certain non-localhost use cases. This is fixed in 10.9.0-b1. | ||||
| CVE-2020-15719 | 5 Mcafee, Openldap, Opensuse and 2 more | 5 Policy Auditor, Openldap, Leap and 2 more | 2024-11-21 | 4.2 Medium |
| libldap in certain third-party OpenLDAP packages has a certificate-validation flaw when the third-party package is asserting RFC6125 support. It considers CN even when there is a non-matching subjectAltName (SAN). This is fixed in, for example, openldap-2.4.46-10.el8 in Red Hat Enterprise Linux. | ||||
| CVE-2020-15604 | 2 Microsoft, Trendmicro | 6 Windows, Antivirus\+ 2019, Internet Security 2019 and 3 more | 2024-11-21 | 7.5 High |
| An incomplete SSL server certification validation vulnerability in the Trend Micro Security 2019 (v15) consumer family of products could allow an attacker to combine this vulnerability with another attack to trick an affected client into downloading a malicious update instead of the expected one. CWE-494: Update files are not properly verified. | ||||
| CVE-2020-15526 | 1 Red-gate | 1 Sql Monitor | 2024-11-21 | 5.9 Medium |
| In Redgate SQL Monitor 7.1.4 through 10.1.6 (inclusive), the scope for disabling some TLS security certificate checks can extend beyond that defined by various options on the Configuration > Notifications pages to disable certificate checking for alert notifications. These TLS security checks are also ignored during monitoring of VMware machines. This would make SQL Monitor vulnerable to potential man-in-the-middle attacks when sending alert notification emails, posting to Slack or posting to webhooks. The vulnerability is fixed in version 10.1.7. | ||||
| CVE-2020-15498 | 1 Asus | 2 Rt-ac1900p, Rt-ac1900p Firmware | 2024-11-21 | 5.9 Medium |
| An issue was discovered on ASUS RT-AC1900P routers before 3.0.0.4.385_20253. The router accepts an arbitrary server certificate for a firmware update. The culprit is the --no-check-certificate option passed to wget tool used to download firmware update files. | ||||
| CVE-2020-15260 | 1 Teluu | 1 Pjsip | 2024-11-21 | 6.8 Medium |
| 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-2020-15134 | 1 Faye Project | 1 Faye | 2024-11-21 | 8 High |
| Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory. | ||||
| CVE-2020-15133 | 1 Faye-websocket Project | 1 Faye-websocket | 2024-11-21 | 8 High |
| In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. The `Faye::WebSocket::Client` class uses the `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `wss:` connection made using this library is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended. | ||||
| CVE-2020-15047 | 1 Trojita Project | 1 Trojita | 2024-11-21 | 5.9 Medium |
| MSA/SMTP.cpp in Trojita before 0.8 ignores certificate-verification errors, which allows man-in-the-middle attackers to spoof SMTP servers. | ||||
| CVE-2020-14981 | 1 Vipre | 1 Password Vault | 2024-11-21 | 5.9 Medium |
| The ThreatTrack VIPRE Password Vault app through 1.100.1090 for iOS has Missing SSL Certificate Validation. | ||||
| CVE-2020-14980 | 1 Sophos | 1 Sophos Secure Email | 2024-11-21 | 5.9 Medium |
| The Sophos Secure Email application through 3.9.4 for Android has Missing SSL Certificate Validation. | ||||
| CVE-2020-14782 | 6 Debian, Mcafee, Netapp and 3 more | 19 Debian Linux, Epolicy Orchestrator, Active Iq Unified Manager and 16 more | 2024-11-21 | 3.7 Low |
| Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N). | ||||
| CVE-2020-14039 | 2 Golang, Opensuse | 2 Go, Leap | 2024-11-21 | 5.3 Medium |
| In Go before 1.13.13 and 1.14.x before 1.14.5, Certificate.Verify may lack a check on the VerifyOptions.KeyUsages EKU requirements (if VerifyOptions.Roots equals nil and the installation is on Windows). Thus, X.509 certificate verification is incomplete. | ||||
| CVE-2020-13955 | 1 Apache | 1 Calcite | 2024-11-21 | 5.9 Medium |
| HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses internally this method to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore. | ||||
| CVE-2020-13645 | 5 Broadcom, Canonical, Fedoraproject and 2 more | 6 Fabric Operating System, Ubuntu Linux, Fedora and 3 more | 2024-11-21 | 6.5 Medium |
| In GNOME glib-networking through 2.64.2, the implementation of GTlsClientConnection skips hostname verification of the server's TLS certificate if the application fails to specify the expected server identity. This is in contrast to its intended documented behavior, to fail the certificate verification. Applications that fail to provide the server identity, including Balsa before 2.5.11 and 2.6.x before 2.6.1, accept a TLS certificate if the certificate is valid for any host. | ||||
| CVE-2020-13616 | 1 Pichi Project | 1 Pichi | 2024-11-21 | 5.9 Medium |
| The boost ASIO wrapper in net/asio.cpp in Pichi before 1.3.0 lacks TLS hostname verification. | ||||
| CVE-2020-13615 | 1 Qore | 1 Qore | 2024-11-21 | 5.9 Medium |
| lib/QoreSocket.cpp in Qore before 0.9.4.2 lacks hostname verification for X.509 certificates. | ||||
| CVE-2020-13614 | 3 Axel Project, Fedoraproject, Opensuse | 4 Axel, Fedora, Backports Sle and 1 more | 2024-11-21 | 5.9 Medium |
| An issue was discovered in ssl.c in Axel before 2.17.8. The TLS implementation lacks hostname verification. | ||||
| CVE-2020-13482 | 3 Em-http-request Project, Fedoraproject, Redhat | 3 Em-http-request, Fedora, Openstack-optools | 2024-11-21 | 7.4 High |
| EM-HTTP-Request 1.1.5 uses the library eventmachine in an insecure way that allows an attacker to perform a man-in-the-middle attack against users of the library. The hostname in a TLS server certificate is not verified. | ||||