An Insecure Update via HTTP vulnerability in Trend Micro Email Encryption Gateway 5.5 could allow an attacker to eavesdrop and tamper with certain types of update data.

A potential vulnerability has been identified in HP Remote Graphics Software’s certificate authentication process version 7.5.0 and earlier.

CFEngine Enterprise 3.15.0 through 3.15.4 has Missing SSL Certificate Validation.

Potentially, SAP Cloud Connector, version - 2.0 communication with the backend is accepted without sufficient validation of the certificate.

A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x.

openssl_x509_check_ip_asc in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.

openssl_x509_check_host in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.

openssl_x509_check_email in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.

Usage of specific command line parameter in MongoDB Tools which was originally intended to just skip hostname checks, may result in MongoDB skipping all certificate validation. This may result in accepting invalid certificates.This issue affects: MongoDB Inc. MongoDB Database Tools 3.6 versions later than 3.6.5; 3.6 versions prior to 3.6.21; 4.0 versions prior to 4.0.21; 4.2 versions prior to 4.2.11; 100 versions prior to 100.2.0. MongoDB Inc. Mongomirror 0 versions later than 0.6.0.

The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. 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.

Icinga 2 v2.8.0 through v2.11.7 and v2.12.2 has an issue where revoked certificates due for renewal will automatically be renewed, ignoring the CRL. This issue is fixed in Icinga 2 v2.11.8 and v2.12.3.

The client applications in 3CX on Windows, the 3CX app for iOS, and the 3CX application for Android through 2022-03-17 lack SSL certificate validation.

An issue was discovered in Mattermost Server before 3.8.2, 3.7.5, and 3.6.7. The X.509 certificate validation can be skipped for a TLS-based e-mail server.

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.

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.

An issue was discovered in Pulse Secure Pulse Connect Secure (PCS) through 2020-04-06. The applet in tncc.jar, executed on macOS, Linux, and Solaris clients when a Host Checker policy is enforced, accepts an arbitrary SSL certificate.

An issue has been found in PowerDNS Recursor versions 4.1.x before 4.1.9 where records in the answer section of responses received from authoritative servers with the AA flag not set were not properly validated, allowing an attacker to bypass DNSSEC validation.

The "Apache NetBeans" autoupdate system does not validate SSL certificates and hostnames for https based downloads. This allows an attacker to intercept downloads of autoupdates and modify the download, potentially injecting malicious code. “Apache NetBeans" versions up to and including 11.2 are affected by this vulnerability.

Jenkins Spira Importer Plugin 3.2.3 and earlier disables SSL/TLS certificate validation for the Jenkins master JVM.

The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. The initial connection to the HTTPS proxy (if an SSLContext isn't given via proxy_config) doesn't verify the hostname of the certificate. This means certificates for different servers that still validate properly with the default urllib3 SSLContext will be silently accepted.

Improper Certificate Validation vulnerability in Micro Focus Application Automation Tools Plugin - Jenkins plugin. The vulnerability affects version 6.7 and earlier versions. The vulnerability could allow unconditionally disabling of SSL/TLS certificates.

A certificate validation issue existed when processing administrator added certificates. This issue was addressed with improved certificate validation. This issue is fixed in iOS 13.6 and iPadOS 13.6, macOS Catalina 10.15.6, tvOS 13.4.8, watchOS 6.2.8. An attacker may have been able to impersonate a trusted website using shared key material for an administrator added certificate.

Jenkins Cadence vManager Plugin 2.7.0 and earlier disabled SSL/TLS and hostname verification globally for the Jenkins master JVM.

Jenkins Bumblebee HP ALM Plugin 4.1.3 and earlier unconditionally disabled SSL/TLS and hostname verification for connections to HP ALM.

An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL before 1.0.2. tunnel.c mishandles certificate validation because hostname comparisons do not consider '\0' characters, as demonstrated by a good.example.com\x00evil.example.com attack.

The ASUS HiVivo aspplication before 5.6.27 for ASUS Watch has Missing SSL Certificate Validation.

The ASUS Vivobaby application before 1.1.09 for Android has Missing SSL Certificate Validation.