Vulnerabilities (CVE)

Filtered by CWE-295
Total 1040 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2020-16197 1 Octopus 2 Octopus Server, Server 2024-11-21 4.0 MEDIUM 4.3 MEDIUM
An issue was discovered in Octopus Deploy 3.4. A deployment target can be configured with an Account or Certificate that is outside the scope of the deployment target. An authorised user can potentially use a certificate that they are not in scope to use. An authorised user is also able to obtain certificate metadata by associating a certificate with certain resources that should fail scope validation.
CVE-2020-16164 1 Ripe 1 Rpki Validator 3 2024-11-21 5.8 MEDIUM 7.4 HIGH
An issue was discovered in RIPE NCC RPKI Validator 3.x through 3.1-2020.07.06.14.28. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X509 Certificate Revocation List files from the RPKI relying party's view. NOTE: some third parties may regard this as a preferred behavior, not a vulnerability
CVE-2020-16163 1 Ripe 1 Rpki Validator 3 2024-11-21 6.4 MEDIUM 9.1 CRITICAL
An issue was discovered in RIPE NCC RPKI Validator 3.x before 3.1-2020.07.06.14.28. RRDP fetches proceed even with a lack of validation of a TLS HTTPS endpoint. This allows remote attackers to bypass intended access restrictions, or to trigger denial of service to traffic directed to co-dependent routing systems. NOTE: third parties assert that the behavior is intentionally permitted by RFC 8182
CVE-2020-16162 1 Ripe 1 Rpki Validator 3 2024-11-21 5.0 MEDIUM 7.5 HIGH
An issue was discovered in RIPE NCC RPKI Validator 3.x through 3.1-2020.07.06.14.28. Missing validation checks on CRL presence or CRL staleness in the X509-based RPKI certificate-tree validation procedure allow remote attackers to bypass intended access restrictions by using revoked certificates. NOTE: there may be counterarguments related to backwards compatibility
CVE-2020-16093 2 Debian, Lemonldap-ng 2 Debian Linux, Lemonldap\ 2024-11-21 N/A 7.5 HIGH
In LemonLDAP::NG (aka lemonldap-ng) through 2.0.8, validity of the X.509 certificate is not checked by default when connecting to remote LDAP backends, because the default configuration of the Net::LDAPS module for Perl is used.
CVE-2020-15813 1 Graylog 1 Graylog 2024-11-21 6.8 MEDIUM 8.1 HIGH
Graylog before 3.3.3 lacks SSL Certificate Validation for LDAP servers. It allows use of an external user/group database stored in LDAP. The connection configuration allows the usage of unencrypted, SSL- or TLS-secured connections. Unfortunately, the Graylog client code (in all versions that support LDAP) does not implement proper certificate validation (regardless of whether the "Allow self-signed certificates" option is used). Therefore, any attacker with the ability to intercept network traffic between a Graylog server and an LDAP server is able to redirect traffic to a different LDAP server (unnoticed by the Graylog server due to the lack of certificate validation), effectively bypassing Graylog's authentication mechanism.
CVE-2020-15732 1 Bitdefender 3 Antivirus Plus, Internet Security, Total Security 2024-11-21 5.0 MEDIUM 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 1 Dogtagpki 1 Dogtagpki 2024-11-21 4.0 MEDIUM 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.0 MEDIUM 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 5.0 MEDIUM 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 4.3 MEDIUM 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 4.3 MEDIUM 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 4.3 MEDIUM 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 6.4 MEDIUM 8.0 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 5.8 MEDIUM 8.0 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 4.3 MEDIUM 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 4.3 MEDIUM 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 4.3 MEDIUM 5.9 MEDIUM
The Sophos Secure Email application through 3.9.4 for Android has Missing SSL Certificate Validation.
CVE-2020-14039 2 Golang, Opensuse 2 Go, Leap 2024-11-21 5.0 MEDIUM 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 4.3 MEDIUM 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.