Heap-based buffer overflow in ARM mbed TLS (formerly PolarSSL) 1.3.x before 1.3.14 and 2.x before 2.1.2 allows remote SSL servers to cause a denial of service (client crash) and possibly execute arbitrary code via a long session ticket name to the session ticket extension, which is not properly handled when creating a ClientHello message to resume a session. NOTE: this identifier was SPLIT from CVE-2015-5291 per ADT3 due to different affected version ranges.

Heap-based buffer overflow in PolarSSL 1.x before 1.2.17 and ARM mbed TLS (formerly PolarSSL) 1.3.x before 1.3.14 and 2.x before 2.1.2 allows remote SSL servers to cause a denial of service (client crash) and possibly execute arbitrary code via a long hostname to the server name indication (SNI) extension, which is not properly handled when creating a ClientHello message. NOTE: this identifier has been SPLIT per ADT3 due to different affected version ranges. See CVE-2015-8036 for the session ticket issue that was introduced in 1.3.0.

In ARM Trusted Firmware 1.3, RO memory is always executable at AArch64 Secure EL1, allowing attackers to bypass the MT_EXECUTE_NEVER protection mechanism. This issue occurs because of inconsistency in the number of execute-never bits (one bit versus two bits).

ARM astcenc 3.2.0 is vulnerable to Buffer Overflow in function encode_ise().

ARM mbed TLS before 1.3.21 and 2.x before 2.1.9, if optional authentication is configured, allows remote attackers to bypass peer authentication via an X.509 certificate chain with many intermediates. NOTE: although mbed TLS was formerly known as PolarSSL, the releases shipped with the PolarSSL name are not affected.

ARM mbedTLS version 2.7.0 and earlier contains a Ciphersuite Allows Incorrectly Signed Certificates vulnerability in mbedtls_ssl_get_verify_result() that can result in ECDSA-signed certificates are accepted, when only RSA-signed ones should be.. This attack appear to be exploitable via Peers negotiate a TLS-ECDH-RSA-* ciphersuite. Any of the peers can then provide an ECDSA-signed certificate, when only an RSA-signed one should be accepted..

An issue was discovered in Mbed TLS 3.x before 3.6.1. With TLS 1.3, when a server enables optional authentication of the client, if the client-provided certificate does not have appropriate values in if keyUsage or extKeyUsage extensions, then the return value of mbedtls_ssl_get_verify_result() would incorrectly have the MBEDTLS_X509_BADCERT_KEY_USAGE and MBEDTLS_X509_BADCERT_KEY_USAGE bits clear. As a result, an attacker that had a certificate valid for uses other than TLS client authentication would nonetheless be able to use it for TLS client authentication. Only TLS 1.3 servers were affected, and only with optional authentication (with required authentication, the handshake would be aborted with a fatal alert).

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).

An issue was discovered in Mbed TLS before 2.25.0 (and before 2.16.9 LTS and before 2.7.18 LTS). A NULL algorithm parameters entry looks identical to an array of REAL (size zero) and thus the certificate is considered valid. However, if the parameters do not match in any way, then the certificate should be considered invalid.

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.

A spoofing vulnerability exists for the Azure IoT Device Provisioning for the C SDK library using the HTTP protocol on Windows platform, aka "Azure IoT SDK Spoofing Vulnerability." This affects C SDK.

A spoofing vulnerability exists when the Azure IoT Device Provisioning AMQP Transport library improperly validates certificates over the AMQP protocol, aka "Azure IoT SDK Spoofing Vulnerability." This affects C# SDK, C SDK, Java SDK.

VOBOT CLOCK before 0.99.30 devices do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information, and consequently execute arbitrary code, via a crafted certificate, as demonstrated by leveraging a hardcoded --no-check-certificate Wget option.

An issue was discovered in the openssl crate before 0.9.0 for Rust. There is an SSL/TLS man-in-the-middle vulnerability because certificate verification is off by default and there is no API for hostname verification.

An unvalidated software update vulnerability in Trend Micro Email Encryption Gateway 5.5 could allow a man-in-the-middle attacker to tamper with an update file and inject their own.

An exploitable vulnerability exists in the HTTP client functionality of the Webroot BrightCloud SDK. The configuration of the HTTP client does not enforce a secure connection by default, resulting in a failure to validate TLS certificates. An attacker could impersonate a remote BrightCloud server to exploit this vulnerability.

A man-in-the-middle vulnerability related to vCenter access was found in Rubrik CDM 3.x and 4.x before 4.0.4-p2. This vulnerability might expose Rubrik user credentials configured to access vCenter as Rubrik clusters did not verify TLS certificates presented by vCenter.

The TLS protocol 1.2 and earlier supports the rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh values for ClientCertificateType but does not directly document the ability to compute the master secret in certain situations with a client secret key and server public key but not a server secret key, which makes it easier for man-in-the-middle attackers to spoof TLS servers by leveraging knowledge of the secret key for an arbitrary installed client X.509 certificate, aka the "Key Compromise Impersonation (KCI)" issue.

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.

Samsung Galaxy Apps before 4.4.01.7 allows modification of the hostname used for load balancing on installations of applications through a man-in-the-middle attack. An attacker may trick Galaxy Apps into using an arbitrary hostname for which the attacker can provide a valid SSL certificate, and emulate the API of the app store to modify existing apps at installation time. The specific flaw involves an HTTP method to obtain the load-balanced hostname that enforces SSL only after obtaining a hostname from the load balancer, and a missing app signature validation in the application XML. An attacker can exploit this vulnerability to achieve Remote Code Execution on the device. The Samsung ID is SVE-2018-12071.

packages/wekan-ldap/server/ldap.js in Wekan before 4.87 can process connections even though they are not authorized by the Certification Authority trust store,

The Scalyr Agent before 2.1.10 has Missing SSL Certificate Validation because, in some circumstances, the openssl binary is called without the -verify_hostname option.

DoTls13CertificateVerify in tls13.c in wolfSSL before 4.7.0 does not cease processing for certain anomalous peer behavior (sending an ED22519, ED448, ECC, or RSA signature without the corresponding certificate). The client side is affected because man-in-the-middle attackers can impersonate TLS 1.3 servers.

The TLS stack in Mono before 3.12.1 allows man-in-the-middle attackers to conduct message skipping attacks and consequently impersonate clients by leveraging missing handshake state validation, aka a "SMACK SKIP-TLS" issue.

An issue was discovered in myStrom WiFi Switch V1 before 2.66, WiFi Switch V2 before 3.80, WiFi Switch EU before 3.80, WiFi Bulb before 2.58, WiFi LED Strip before 3.80, WiFi Button before 2.73, and WiFi Button Plus before 2.73. The SSL/TLS server certificate in the device to cloud communication was not verified by the device. As a result, an attacker in control of the network traffic of a device could have taken control of a device by intercepting and modifying commands issued from the server to the device in a Man-in-the-Middle attack. This included the ability to inject firmware update commands into the communication and cause the device to install maliciously modified firmware.

An issue was discovered in VirusTotal. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

An issue was discovered in F-Secure XFENCE and Little Flocker. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

An issue was discovered in Objective-See KnockKnock, LuLu, TaskExplorer, WhatsYourSign, and procInfo. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

An issue was discovered in Google Santa and molcodesignchecker. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

An issue was discovered in Yelp OSXCollector. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

An issue was discovered in MikroTik RouterOS 6.41.4. Missing OpenVPN server certificate verification allows a remote unauthenticated attacker capable of intercepting client traffic to act as a malicious OpenVPN server. This may allow the attacker to gain access to the client's internal network (for example, at site-to-site tunnels).

The (1) CertGetCertificateChain, (2) CertVerifyCertificateChainPolicy, and (3) WinVerifyTrust APIs within the CryptoAPI for Microsoft products including Microsoft Windows 98 through XP, Office for Mac, Internet Explorer for Mac, and Outlook Express for Mac, do not properly verify the Basic Constraints of intermediate CA-signed X.509 certificates, which allows remote attackers to spoof the certificates of trusted sites via a man-in-the-middle attack for SSL sessions, as originally reported for Internet Explorer and IIS.

brianleroux tiny-json-http version all versions since commit 9b8e74a232bba4701844e07bcba794173b0238a8 (Oct 29 2016) contains a Missing SSL certificate validation vulnerability in The libraries core functionality is affected. that can result in Exposes the user to man-in-the-middle attacks.

Busybox contains a Missing SSL certificate validation vulnerability in The "busybox wget" applet that can result in arbitrary code execution. This attack appear to be exploitable via Simply download any file over HTTPS using "busybox wget https://compromised-domain.com/important-file".

A man in the middle vulnerability exists in Jenkins vSphere Plugin 2.16 and older in VSphere.java that disables SSL/TLS certificate validation by default.

Improper validation of the cloud certificate chain in Mobile Connect allows man-in-the-middle attack to impersonate the legitimate Command Centre Server. This issue affects: Gallagher Command Centre Mobile Connect for Android 15 versions prior to 15.04.040; version 14 and prior versions.

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 without full verification of the SSL/TLS certificate due to the default setting of httpClient. 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.

Multiple vulnerabilities in Cisco Jabber for Windows, Cisco Jabber for MacOS, and Cisco Jabber for mobile platforms could allow an attacker to execute arbitrary programs on the underlying operating system with elevated privileges, access sensitive information, intercept protected network traffic, or cause a denial of service (DoS) condition. For more information about these vulnerabilities, see the Details section of this advisory.

Acceptance of invalid/self-signed TLS certificates in "Foxit PDF - PDF reader, editor, form, signature" before 5.4 for iOS allows a man-in-the-middle and/or physically proximate attacker to silently intercept login information (username/password), in addition to the static authentication token if the user is already logged in.

The (1) update and (2) package-installation features in MODX Revolution 2.5.4-pl and earlier do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and trigger the execution of arbitrary code via a crafted certificate.

A missing verification of the TLS host in Nextcloud Mail 1.1.3 allowed a man in the middle attack.

An issue was discovered in Couchbase Sync Gateway 3.x before 3.0.2. Admin credentials are not verified when using X.509 client-certificate authentication from Sync Gateway to Couchbase Server. When Sync Gateway is configured to authenticate with Couchbase Server using X.509 client certificates, the admin credentials provided to the Admin REST API are ignored, resulting in privilege escalation for unauthenticated users. The Public REST API is not impacted by this issue. A workaround is to replace X.509 certificate based authentication with Username and Password authentication inside the bootstrap configuration.

Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. 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.

In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties. The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.

A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting in potential certificate validation vulnerabilities, denial of service and possible remote code execution. In order to trigger this vulnerability, the attacker needs to supply a malicious x509 certificate to either a server or a client application using this library.

It was found that the Active Directory Plugin for Jenkins up to and including version 2.2 did not verify certificates of the Active Directory server, thereby enabling Man-in-the-Middle attacks.

Pandora iOS app prior to version 8.3.2 fails to properly validate SSL certificates provided by HTTPS connections, which may enable an attacker to conduct man-in-the-middle (MITM) attacks.

It was found that jenkins-ssh-slaves-plugin before version 1.15 did not perform host key verification, thereby enabling Man-in-the-Middle attacks.

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.

Envoy is an open source edge and service proxy, designed for cloud-native applications. Envoy's tls allows re-use when some cert validation settings have changed from their default configuration. The only workaround for this issue is to ensure that default tls settings are used. Users are advised to upgrade.