Jenkins VMware Lab Manager Slaves Plugin 0.2.8 and earlier disables SSL/TLS and hostname verification globally for the Jenkins master JVM.

Jenkins ElectricFlow Plugin 1.1.5 and earlier disabled SSL/TLS and hostname verification globally for the Jenkins master JVM when MultipartUtility.java is used to upload files.

Jenkins Codefresh Integration Plugin 1.8 and earlier disables SSL/TLS and hostname verification globally for the Jenkins master JVM.

Jenkins NeuVector Vulnerability Scanner Plugin 1.22 and earlier unconditionally disables SSL/TLS certificate and hostname validation when connecting to a configured NeuVector Vulnerability Scanner server.

An improper certificate validation vulnerability exists in Jenkins Active Directory Plugin 2.10 and earlier in src/main/java/hudson/plugins/active_directory/ActiveDirectoryDomain.java, src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java, src/main/java/hudson/plugins/active_directory/ActiveDirectoryUnixAuthenticationProvider.java that allows attackers to impersonate the Active Directory server Jenkins connects to for authentication if Jenkins is configured to use StartTLS.

A man in the middle vulnerability exists in Jenkins TraceTronic ECU-TEST Plugin 2.3 and earlier in ATXPublisher.java, ATXValidator.java that allows attackers to impersonate any service that Jenkins connects to.

A man in the middle vulnerability exists in Jenkins Inedo ProGet Plugin 0.8 and earlier in ProGetApi.java, ProGetConfig.java, ProGetConfiguration.java that allows attackers to impersonate any service that Jenkins connects to.

A man in the middle vulnerability exists in Jenkins Inedo BuildMaster Plugin 1.3 and earlier in BuildMasterConfiguration.java, BuildMasterConfig.java, BuildMasterApi.java that allows attackers to impersonate any service that Jenkins connects to.

A man in the middle vulnerability exists in Jenkins CollabNet Plugin 2.0.4 and earlier in CollabNetApp.java, CollabNetPlugin.java, CNFormFieldValidator.java that allows attackers to impersonate any service that Jenkins connects to.

Jenkins Git client Plugin 3.11.0 and earlier does not perform SSH host key verification when connecting to Git repositories via SSH, enabling man-in-the-middle attacks.

Jenkins View26 Test-Reporting Plugin 1.0.7 and earlier does not perform hostname validation when connecting to the configured View26 server that could be abused using a man-in-the-middle attack to intercept these connections.

Traefik is an HTTP reverse proxy and load balancer. Prior to version 2.6.1, Traefik skips the router transport layer security (TLS) configuration when the host header is a fully qualified domain name (FQDN). For a request, the TLS configuration choice can be different than the router choice, which implies the use of a wrong TLS configuration. When sending a request using FQDN handled by a router configured with a dedicated TLS configuration, the TLS configuration falls back to the default configuration that might not correspond to the configured one. If the CNAME flattening is enabled, the selected TLS configuration is the SNI one and the routing uses the CNAME value, so this can skip the expected TLS configuration. Version 2.6.1 contains a patch for this issue. As a workaround, one may add the FDQN to the host rule. However, there is no workaround if the CNAME flattening is enabled.

Dell PowerScale OneFS, 8.2.x-9.3.x, contains a Improper Certificate Validation. A unauthenticated remote attacker could potentially exploit this vulnerability, leading to a man-in-the-middle capture of administrative credentials.

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.

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.

Akeo Consulting Rufus prior to version 2.17.1187 does not adequately validate the integrity of updates downloaded over HTTP, allowing an attacker to easily convince a user to execute arbitrary code

It was found that Kubernetes as used by Openshift Enterprise 3 did not correctly validate X.509 client intermediate certificate host name fields. An attacker could use this flaw to bypass authentication requirements by using a specially crafted X.509 certificate.

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 flaw was found in all versions of kubeclient up to (but not including) v4.9.3, the Ruby client for Kubernetes REST API, in the way it parsed kubeconfig files. When the kubeconfig file does not configure custom CA to verify certs, kubeclient ends up accepting any certificate (it wrongly returns VERIFY_NONE). Ruby applications that leverage kubeclient to parse kubeconfig files are susceptible to Man-in-the-middle attacks (MITM).

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.

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.

pulp-consumer-client 2.4.0 through 2.6.3 does not check the server's TLS certificate signatures when retrieving the server's public key upon registration.

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.

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.

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,

libvirt version 2.3.0 and later is vulnerable to a bad default configuration of "verify-peer=no" passed to QEMU by libvirt resulting in a failure to validate SSL/TLS certificates by default.

NetApp Plug-in for Symantec NetBackup prior to version 2.0.1 makes use of a non-unique server certificate, making it vulnerable to impersonation.

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.

A misconfiguration exists in the MQTTS functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. This misconfiguration significantly simplifies a man-in-the-middle attack, which directly leads to control of device functionality.

In Java-WebSocket less than or equal to 1.4.1, there is an Improper Validation of Certificate with Host Mismatch where WebSocketClient does not perform SSL hostname validation. This has been patched in 1.5.0.

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.

Open Build Service before version 0.165.4 diddn't validate TLS certificates for HTTPS connections with the osc client binary

A vulnerability in the Transport Layer Security (TLS) certificate validation functionality of Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, remote attacker to perform insecure TLS client authentication on an affected device. The vulnerability is due to insufficient TLS client certificate validations for certificates sent between the various components of an ACI fabric. An attacker who has possession of a certificate that is trusted by the Cisco Manufacturing CA and the corresponding private key could exploit this vulnerability by presenting a valid certificate while attempting to connect to the targeted device. An exploit could allow the attacker to gain full control of all other components within the ACI fabric of an affected device.

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.

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

Dell EMC Unisphere for PowerMax versions prior to 9.1.0.17, Dell EMC Unisphere for PowerMax Virtual Appliance versions prior to 9.1.0.17, and PowerMax OS Release 5978 contain an improper certificate validation vulnerability. An unauthenticated remote attacker may potentially exploit this vulnerability to carry out a man-in-the-middle attack by supplying a crafted certificate and intercepting the victim's traffic to view or modify a victim's data in transit.

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.

Improper certificate validation vulnerability in OpenVPN client in Synology Router Manager (SRM) before 1.2.4-8081 allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Improper certificate validation vulnerability in OpenVPN client in Synology DiskStation Manager (DSM) before 6.2.3-25426-2 allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

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.

An issue was discovered in PrimeKey EJBCA 6.x and 7.x before 7.4.1. When using a client certificate to enroll over the EST protocol, no revocation check is performed on that certificate. This vulnerability can only affect a system that has EST configured, uses client certificates to authenticate enrollment, and has had such a certificate revoked. This certificate needs to belong to a role that is authorized to enroll new end entities. (To completely mitigate this problem prior to upgrade, remove any revoked client certificates from their respective roles.)

The Scalyr Agent before 2.1.10 has Missing SSL Certificate Validation because, in some circumstances, native Python code is used that lacks a comparison of the hostname to commonName and subjectAltName.

Splunk-SDK-Python before 1.6.6 does not properly verify untrusted TLS server certificates, which could result in man-in-the-middle attacks.

There is Missing SSL Certificate Validation in the pw3270 terminal emulator before version 5.1.

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