The Certificate Trust Policy component in Apple Mac OS X before 10.6.8 does not perform CRL checking for Extended Validation (EV) certificates that lack OCSP URLs, which might allow man-in-the-middle attackers to spoof an SSL server via a revoked certificate.

offlineimap before 6.3.2 does not check for SSL server certificate validation when "ssl = yes" option is specified which can allow man-in-the-middle attacks.

Nextcloud Desktop Client before 3.3.1 is vulnerable to improper certificate validation due to lack of SSL certificate verification when using the "Register with a Provider" flow.

The vulnerability have been reported to affect earlier versions of Helpdesk. If exploited, this improper certificate validation vulnerability could allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. QNAP has already fixed the issue in Helpdesk 3.0.3 and later.

Mercurial before 1.6.4 fails to verify the Common Name field of SSL certificates which allows remote attackers who acquire a certificate signed by a Certificate Authority to perform a man-in-the-middle attack.

Nimble is a package manager for the Nim programming language. In Nim release versions before versions 1.2.10 and 1.4.4, "nimble refresh" fetches a list of Nimble packages over HTTPS by default. In case of error it falls back to a non-TLS URL http://irclogs.nim-lang.org/packages.json. An attacker able to perform MitM can deliver a modified package list containing malicious software packages. If the packages are installed and used the attack escalates to untrusted code execution.

Mozilla Network Security Services (NSS) before 3.12.3, Firefox before 3.0.13, Thunderbird before 2.0.0.23, and SeaMonkey before 1.1.18 do not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority. NOTE: this was originally reported for Firefox before 3.5.

Man-in-the-middle vulnerability in Micro Focus Self Service Password Reset, affecting all versions prior to 4.4.0.4. The vulnerability could exploit invalid certificate validation and may result in a man-in-the-middle attack.

The libwww-perl LWP::Protocol::https module 6.04 through 6.06 for Perl, when using IO::Socket::SSL as the SSL socket class, allows attackers to disable server certificate validation via the (1) HTTPS_CA_DIR or (2) HTTPS_CA_FILE environment variable.

The Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does not close the connection to the bookkeeper server when TLS hostname verification fails. This leaves the bookkeeper client vulnerable to a man in the middle attack. The problem affects BookKeeper client prior to versions 4.14.6 and 4.15.1.

IBM QRadar SIEM 7.5 could allow an unauthorized user to perform unauthorized actions due to improper certificate validation. IBM X-Force ID: 275706.

daneren2005 DSub for Subsonic (Android client) version 5.4.1 contains a CWE-295: Improper Certificate Validation vulnerability in HTTPS Client that can result in Any non-CA signed server certificate, including self signed and expired, are accepted by the client. This attack appear to be exploitable via The victim connects to a server that's MITM/Proxied by an attacker.

Jenkins Proxmox Plugin 0.6.0 and earlier disables SSL/TLS certificate validation globally for the Jenkins controller JVM when configured to ignore SSL/TLS issues.

A certificate parsing issue was addressed with improved checks. This issue is fixed in tvOS 15.5, iOS 15.5 and iPadOS 15.5, Security Update 2022-004 Catalina, watchOS 8.6, macOS Big Sur 11.6.6, macOS Monterey 12.4. A malicious app may be able to bypass signature validation.

In Mellium mellium.im/xmpp through 0.21.0, an attacker capable of spoofing DNS TXT records can redirect a WebSocket connection request to a server under their control without causing TLS certificate verification to fail. This occurs because the wrong host name is selected during this verification.

Pion DTLS is a Go implementation of Datagram Transport Layer Security. Prior to version 2.1.5, a DTLS Client could provide a Certificate that it doesn't posses the private key for and Pion DTLS wouldn't reject it. This issue affects users that are using Client certificates only. The connection itself is still secure. The Certificate provided by clients can't be trusted when using a Pion DTLS server prior to version 2.1.5. Users should upgrade to version 2.1.5 to receive a patch. There are currently no known workarounds.

Nessus AMI versions 8.12.0 and earlier were found to either not validate, or incorrectly validate, a certificate which could allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack.

IBM Security Secret Server prior to 10.9 could allow an attacker to bypass SSL security due to improper certificate validation. IBM X-Force ID: 178180.

The _gnutls_x509_verify_certificate function in lib/x509/verify.c in libgnutls in GnuTLS before 2.6.1 trusts certificate chains in which the last certificate is an arbitrary trusted, self-signed certificate, which allows man-in-the-middle attackers to insert a spoofed certificate for any Distinguished Name (DN).

OWASP Zed Attack Proxy (ZAP) through w2022-03-21 does not verify the TLS certificate chain of an HTTPS server.

Envoy is an open source edge and service proxy, designed for cloud-native applications. The default_validator.cc implementation used to implement the default certificate validation routines has a "type confusion" bug when processing subjectAltNames. This processing allows, for example, an rfc822Name or uniformResourceIndicator to be authenticated as a domain name. This confusion allows for the bypassing of nameConstraints, as processed by the underlying OpenSSL/BoringSSL implementation, exposing the possibility of impersonation of arbitrary servers. As a result Envoy will trust upstream certificates that should not be trusted.

An issue was discovered in Arm Mbed TLS before 2.24.0. It incorrectly uses a revocationDate check when deciding whether to honor certificate revocation via a CRL. In some situations, an attacker can exploit this by changing the local clock.

An issue was discovered in Mbed TLS before 2.24.0. The verification of X.509 certificates when matching the expected common name (the cn argument of mbedtls_x509_crt_verify) with the actual certificate name is mishandled: when the subjecAltName extension is present, the expected name is compared to any name in that extension regardless of its type. This means that an attacker could impersonate a 4-byte or 16-byte domain by getting a certificate for the corresponding IPv4 or IPv6 address (this would require the attacker to control that IP address, though).

IBM SAN Volume Controller, IBM Storwize, IBM FlashSystem and IBM Storage Virtualize 8.6 products could allow a remote attacker to spoof a trusted system that would not be correctly validated by the Storwize server. This could lead to a user connecting to a malicious host, believing that it was a trusted system and deceived into accepting spoofed data. IBM X-Force ID: 271016.

The function `OCSP_basic_verify` verifies the signer certificate on an OCSP response. In the case where the (non-default) flag OCSP_NOCHECKS is used then the response will be positive (meaning a successful verification) even in the case where the response signing certificate fails to verify. It is anticipated that most users of `OCSP_basic_verify` will not use the OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return a negative value (indicating a fatal error) in the case of a certificate verification failure. The normal expected return value in this case would be 0. This issue also impacts the command line OpenSSL "ocsp" application. When verifying an ocsp response with the "-no_cert_checks" option the command line application will report that the verification is successful even though it has in fact failed. In this case the incorrect successful response will also be accompanied by error messages showing the failure and contradicting the apparently successful result. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).

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.

In wolfSSL before 5.2.0, certificate validation may be bypassed during attempted authentication by a TLS 1.3 client to a TLS 1.3 server. This occurs when the sig_algo field differs between the certificate_verify message and the certificate message.

It was discovered that rpm-ostree and rpm-ostree-client before 2017.3 fail to properly check GPG signatures on packages when doing layering. Packages with unsigned or badly signed content could fail to be rejected as expected. This issue is partially mitigated on RHEL Atomic Host, where certificate pinning is used by default.

An exploitable vulnerability exists in the filtering functionality of Circle with Disney. SSL certificates for specific domain names can cause the Bluecoat library to accept a different certificate than intended. An attacker can host an HTTPS server with this certificate to trigger this vulnerability.

In mainwindow.cpp in Shotcut before 20.09.13, the upgrade check misuses TLS because of setPeerVerifyMode(QSslSocket::VerifyNone). A man-in-the-middle attacker could offer a spoofed download resource.

In voloko twitter-stream 0.1.10, missing TLS hostname validation allows an attacker to perform a man-in-the-middle attack against users of the library (because eventmachine is misused).

ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.

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.

In fence-agents before 4.0.17 does not verify remote SSL certificates in the fence_cisco_ucs.py script which can potentially allow for man-in-the-middle attackers to spoof SSL servers via arbitrary SSL certificates.

Google Chrome caches TLS sessions before certificate validation occurs.

Certain NETGEAR devices are affected by Missing SSL Certificate Validation. This affects R7000 1.0.9.6_1.2.19 through 1.0.11.100_10.2.10, and possibly R6120, R7800, R6220, R8000, R6350, R9000, R6400, RAX120, R6400v2, RBR20, R6800, XR300, R6850, XR500, and R7000P.

When performing add-on updates, certificate chains terminating in non-built-in-roots were rejected (even if they were legitimately added by an administrator.) This could have caused add-ons to become out-of-date silently without notification to the user. This vulnerability affects Firefox ESR < 68.10, Firefox < 78, and Thunderbird < 68.10.0.

HTTPSConnections in OpenStack Keystone 2013, OpenStack Compute 2013.1, and possibly other OpenStack components, fail to validate server-side SSL certificates.

Odyssey passes to client unencrypted bytes from man-in-the-middle When Odyssey storage is configured to use the PostgreSQL server using 'trust' authentication with a 'clientcert' requirement or to use 'cert' authentication, a man-in-the-middle attacker can inject false responses to the client's first few queries. Despite the use of SSL certificate verification and encryption, Odyssey will pass these results to client as if they originated from valid server. This is similar to CVE-2021-23222 for PostgreSQL.

When parsing the AIA-Extension field of a client certificate, Apache Tomcat Native Connector 1.2.0 to 1.2.14 and 1.1.23 to 1.1.34 did not correctly handle fields longer than 127 bytes. The result of the parsing error was to skip the OCSP check. It was therefore possible for client certificates that should have been rejected (if the OCSP check had been made) to be accepted. Users not using OCSP checks are not affected by this vulnerability.

A Improper Certificate Validation vulnerability in susestudio-common of SUSE Studio onsite allows remote attackers to MITM connections to the repositories, which allows the modification of packages received over these connections. This issue affects: SUSE Studio onsite susestudio-common version 1.3.17-56.6.3 and prior versions.

vdsm: certificate generation upon node creation allowing vdsm to start and serve requests from anyone who has a matching key (and certificate)

Incorrect certificate validation in InvokeHTTP on Apache NiFi MiNiFi C++ versions 0.13 to 0.14 allows an intermediary to present a forged certificate during TLS handshake negotation. The Disable Peer Verification property of InvokeHTTP was effectively flipped, disabling verification by default, when using HTTPS. Mitigation: Set the Disable Peer Verification property of InvokeHTTP to true when using MiNiFi C++ versions 0.13.0 or 0.14.0. Upgrading to MiNiFi C++ 0.15.0 corrects the default behavior.

Apache Libcloud before 0.11.1 uses an incorrect regular expression during verification of whether 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 crafted certificate.

Cisco IronPort Web Security Appliance does not check for certificate revocation which could lead to MITM attacks

Prior to v 7.6, the Install Norton Security (INS) product can be susceptible to a certificate spoofing vulnerability, which is a type of attack whereby a maliciously procured certificate binds the public key of an attacker to the domain name of the target.

A flaw in Mozilla's embedded certificate code might allow web sites to install root certificates on devices without user approval.

An improper certificate validation vulnerability exists in curl <v8.1.0 in the way it supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`.

IBM Security Guardium 10.0, 10.0.1, 10.1, 10.1.2, 10.1.3, 10.1.4, and 10.5 does not validate, or incorrectly validates, a certificate. This weakness might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) techniques. IBM X-Force ID: 124740.