ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.

The PrinterLogic Print Management software, versions up to and including 18.3.1.96, does not validate, or incorrectly validates, the PrinterLogic management portal's SSL certificate. When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.

A vulnerability has been identified in Siveillance VMS Video for Android (All versions < V12.1a (2018 R1)), Siveillance VMS Video for iOS (All versions < V12.1a (2018 R1)). Improper certificate validation could allow an attacker in a privileged network position to read data from and write data to the encrypted communication channel between the app and a server. The security vulnerability could be exploited by an attacker in a privileged network position which allows intercepting the communication channel between the affected app and a server (such as Man-in-the-Middle). Furthermore, an attacker must be able to generate a certificate that results for the validation algorithm in a checksum identical to a trusted certificate. Successful exploitation requires no user interaction. The vulnerability could allow reading data from and writing data to the encrypted communication channel between the app and a server, impacting the communication's confidentiality and integrity. At the time of advisory publication no public exploitation of this security vulnerability was known. Siemens confirms the security vulnerability and provides mitigations to resolve the security issue.

In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs.

Improper following of a certificate's chain of trust exists in SkyBridge MB-A200 firmware Ver. 01.00.05 and earlier, and SkyBridge BASIC MB-A130 firmware Ver. 1.4.1 and earlier, which may allow a remote unauthenticated attacker to eavesdrop on or alter the communication sent to the WebUI of the product.

HCL AppScan Source <= 10.6.0 does not properly validate a TLS/SSL certificate for an executable.

The Apache Qpid Proton-J transport includes an optional wrapper layer to perform TLS, enabled by use of the 'transport.ssl(...)' methods. Unless a verification mode was explicitly configured, client and server modes previously defaulted as documented to not verifying a peer certificate, with options to configure this explicitly or select a certificate verification mode with or without hostname verification being performed. The latter hostname verifying mode was not implemented in Apache Qpid Proton-J versions 0.3 to 0.29.0, with attempts to use it resulting in an exception. This left only the option to verify the certificate is trusted, leaving such a client vulnerable to Man In The Middle (MITM) attack. Uses of the Proton-J protocol engine which do not utilise the optional transport TLS wrapper are not impacted, e.g. usage within Qpid JMS. Uses of Proton-J utilising the optional transport TLS wrapper layer that wish to enable hostname verification must be upgraded to version 0.30.0 or later and utilise the VerifyMode#VERIFY_PEER_NAME configuration, which is now the default for client mode usage unless configured otherwise.

Dell Networking OS10 versions prior to 10.4.3.0 contain a vulnerability in the Phone Home feature which does not properly validate the server's certificate authority during TLS handshake. Use of an invalid or malicious certificate could potentially allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack.

In versions of NGINX Controller prior to 3.2.0, communication between NGINX Controller and NGINX Plus instances skip TLS verification by default.

IBM Security Guardium EcoSystem 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) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host. IBM X-Force ID: 141417.

An improper certificate validation vulnerability [CWE-295] in FortiClientWindows 6.4 all versions, 7.0.0 through 7.0.7, FortiClientMac 6.4 all versions, 7.0 all versions, 7.2.0 through 7.2.4, FortiClientLinux 6.4 all versions, 7.0 all versions, 7.2.0 through 7.2.4, FortiClientAndroid 6.4 all versions, 7.0 all versions, 7.2.0 and FortiClientiOS 5.6 all versions, 6.0.0 through 6.0.1, 7.0.0 through 7.0.6 SAML SSO feature may allow an unauthenticated attacker to man-in-the-middle the communication between the FortiClient and  both the service provider and the identity provider.

In SaltStack Salt before 3002.5, when authenticating to services using certain modules, the SSL certificate is not always validated.

libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing.

Certain Liferay products are affected by: Missing SSL Certificate Validation in the Dynamic Data Mapping module's REST data providers. This affects Liferay Portal 7.1.0 through 7.4.2 and Liferay DXP 7.1 before fix pack 27, 7.2 before fix pack 17, and 7.3 before service pack 3.

An improper certificate validation vulnerability [CWE-295] in FortiOS 7.2.0 through 7.2.3, 7.0.0 through 7.0.7, 6.4 all versions, 6.2 all versions, 6.0 all versions and FortiProxy 7.0.0 through 7.0.6, 2.0 all versions, 1.2 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the FortiOS/FortiProxy device and remote servers hosting threat feeds (when the latter are configured as Fabric connectors in FortiOS/FortiProxy)

In BIG-IP Versions 15.1.x before 15.1.6.1, 14.1.x before 14.1.5, and all versions of 13.1.x, Traffic Intelligence feeds, which use HTTPS, do not verify the remote endpoint identity, allowing for potential data poisoning. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

'Hulu / フールー' App for iOS versions prior to 3.0.81 improperly verifies server certificates, which may allow an attacker to eavesdrop on an encrypted communication via a man-in-the-middle attack.

lib/oauth/consumer.rb in the oauth-ruby gem through 0.5.4 for Ruby does not verify server X.509 certificates if a certificate bundle cannot be found, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information.

In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP support did not verify certificates when used with TLS, allowing an attacker to MITM connections.

The Motorola MBP853 firmware does not correctly validate server certificates. This allows for a Man in The Middle (MiTM) attack to take place between a Motorola MBP853 camera and the servers it communicates with. In one such instance, it was identified that the device was downloading what appeared to be a client certificate.

The LINE MUSIC for Android version 3.1.0 to versions prior to 3.6.5 does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

The ANA App for iOS version 4.0.22 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

The DHC Online Shop App for Android version 3.2.0 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

A vulnerability in the certificate management subsystem of Cisco AnyConnect Network Access Manager and of Cisco AnyConnect Secure Mobility Client for iOS, Mac OS X, Android, Windows, and Linux could allow an unauthenticated, remote attacker to bypass the TLS certificate check when downloading certain configuration files. The vulnerability is due to improper use of Simple Certificate Enrollment Protocol and improper server certificate validation. An attacker could exploit this vulnerability by preparing malicious profile and localization files for Cisco AnyConnect to use. A successful exploit could allow the attacker to remotely change the configuration profile, a certificate, or the localization data used by AnyConnect Secure Mobility Client. Cisco Bug IDs: CSCvh23141.

The iRemoconWiFi App for Android version 4.1.7 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Savitech driver packages for Windows silently install a self-signed certificate into the Trusted Root Certification Authorities store, aka "Inaudible Subversion."

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.

An Improper Certificate Validation weakness in the SRX Series Application Identification (app-id) signature update client of Juniper Networks Junos OS allows an attacker to perform Man-in-the-Middle (MitM) attacks which may compromise the integrity and confidentiality of the device. This issue affects: Juniper Networks Junos OS 15.1X49 versions prior to 15.1X49-D120 on SRX Series devices. No other versions of Junos OS are affected.

The int_x509_param_set_hosts function in lib/libcrypto/x509/x509_vpm.c in LibreSSL 2.7.0 before 2.7.1 does not support a certain special case of a zero name length, which causes silent omission of hostname verification, and consequently allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate. NOTE: the LibreSSL documentation indicates that this special case is supported, but the BoringSSL documentation does not.

The Thycotic Password Manager Secret Server application through 2.3 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

In rfb/CSecurityTLS.cxx and rfb/CSecurityTLS.java in TigerVNC before 1.11.0, viewers mishandle TLS certificate exceptions. They store the certificates as authorities, meaning that the owner of a certificate could impersonate any server after a client had added an exception.

em-imap 0.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.

The SSLVerifySignedServerKeyExchange function in libsecurity_ssl/lib/sslKeyExchange.c in the Secure Transport feature in the Data Security component in Apple iOS 6.x before 6.1.6 and 7.x before 7.0.6, Apple TV 6.x before 6.0.2, and Apple OS X 10.9.x before 10.9.2 does not check the signature in a TLS Server Key Exchange message, which allows man-in-the-middle attackers to spoof SSL servers by (1) using an arbitrary private key for the signing step or (2) omitting the signing step.

The ServerTrustManager component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify basicConstraints and nameConstraints in X.509 certificate chains from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate chain.

WebHybridClient.java in PayPal 5.3 and earlier for Android ignores SSL errors, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information.

A vulnerability was found in HTC One/Sense 4.x. It has been rated as problematic. Affected by this issue is the certification validation of the mail client. An exploit has been disclosed to the public and may be used.

The mAadhaar application 1.2.7 for Android lacks SSL Certificate Validation, leading to man-in-the-middle attacks against requests for FAQs or Help.

Burp Suite Community Edition 1.7.32 and 1.7.33 fail to validate the server certificate in a couple of HTTPS requests which allows a man in the middle to modify or view traffic.

TLS hostname verification when using the Apache ActiveMQ Client before 5.15.6 was missing which could make the client vulnerable to a MITM attack between a Java application using the ActiveMQ client and the ActiveMQ server. This is now enabled by default.

An Improper Certificate Validation weakness in the Juniper Networks Junos OS allows an attacker to perform Person-in-the-Middle (PitM) attacks when a system script is fetched from a remote source at a specified HTTPS URL, which may compromise the integrity and confidentiality of the device. The following command can be executed by an administrator via the CLI to refresh a script from a remote location, which is affected from this vulnerability: >request system scripts refresh-from (commit | event | extension-service | op | snmp) file filename url <https-url> This issue affects: Juniper Networks Junos OS All versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R3-S7; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2; 21.1 versions prior to 21.1R1-S1, 21.1R2.

A vulnerability in the Cisco Advanced Malware Protection (AMP) for Endpoints integration of Cisco AsyncOS for Cisco Email Security Appliance (ESA) and Cisco Web Security Appliance (WSA) could allow an unauthenticated, remote attacker to intercept traffic between an affected device and the AMP servers. This vulnerability is due to improper certificate validation when an affected device establishes TLS connections. A man-in-the-middle attacker could exploit this vulnerability by sending a crafted TLS packet to an affected device. A successful exploit could allow the attacker to spoof a trusted host and then extract sensitive information or alter certain API requests.

A vulnerability in the Zero Touch Provisioning feature of the Cisco SD-WAN Solution could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data by using an invalid certificate. The vulnerability is due to insufficient certificate validation by the affected software. An attacker could exploit this vulnerability by supplying a crafted certificate to an affected device. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on user connections to the affected software.

It was found that Satellite 5 configured with SSL/TLS for the PostgreSQL backend failed to correctly validate X.509 server certificate host name fields. A man-in-the-middle attacker could use this flaw to spoof a PostgreSQL server using a specially crafted X.509 certificate.

In F5 BIG-IP PEM 12.1.0 through 12.1.2 when downloading the Type Allocation Code (TAC) database file via HTTPS, the server's certificate is not verified. Attackers in a privileged network position may be able to launch a man-in-the-middle attack against these connections. TAC databases are used in BIG-IP PEM for Device Type and OS (DTOS) and Tethering detection. Customers not using BIG-IP PEM, not configuring downloads of TAC database files, or not using HTTP for that download are not affected.

The Chase mobile banking application for Android 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, related to overriding the default X509TrustManager. NOTE: this vulnerability was fixed in the summer of 2012, but the version number was not changed or is not known.

Incorrect validation of the TLS SNI hostname in osquery versions after 2.9.0 and before 4.2.0 could allow an attacker to MITM osquery traffic in the absence of a configured root chain of trust.

X509 certificate verification was not correctly implemented in the early access "user id" feature in the F5 BIG-IP Advanced Firewall Manager versions 13.0.0, 12.1.0-12.1.2, and 11.6.0-11.6.2, and thus did not properly validate the remote server's identity on certain versions of BIG-IP.

The contribution feature in Zamboni 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, related to use of the Python urllib2 library.

WeeChat (aka Wee Enhanced Environment for Chat) 3.2 to 3.4 before 3.4.1 does not properly verify the TLS certificate of the server, after certain GnuTLS options are changed, which allows man-in-the-middle attackers to spoof a TLS chat server via an arbitrary certificate. NOTE: this only affects situations where weechat.network.gnutls_ca_system or weechat.network.gnutls_ca_user is changed without a WeeChat restart.

A vulnerability in certification validation routines of Cisco ThousandEyes Endpoint Agent for macOS and RoomOS could allow an unauthenticated, remote attacker to intercept or manipulate metrics information. This vulnerability exists because the affected software does not properly validate certificates for hosted metrics services. An on-path attacker could exploit this vulnerability by intercepting network traffic using a crafted certificate. A successful exploit could allow the attacker to masquerade as a trusted host and monitor or change communications between the remote metrics service and the vulnerable client.