IBM Security Verify Access Docker 10.0.0 through 10.0.6 could allow a local user to escalate their privileges due to improper certificate validation. IBM X-Force ID: 292416.

IBM Security Verify Privilege On-Premises 11.5 does not validate, or incorrectly validates, a certificate which could disclose sensitive information which could aid further attacks against the system. IBM X-Force ID: 240455.

IBM OpenPages with Watson 8.3 and 9.0  could allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery.

IBM Cognos Controller 11.0.0 through 11.0.1 and IBM Controller 11.1.0 could allow an unauthorized user to obtain valid tokens to gain access to protected resources due to improper certificate validation.

IBM MQ Appliance and IBM MQ AMQP Channels 8.0, 9.0 LTS, 9.1 LTS, and 9.1 CD do not correctly block or allow clients based on the certificate distinguished name SSLPEER setting. IBM X-Force ID: 177403.

IBM Security Identity Governance and Intelligence 5.2.6 could allow an attacker to obtain sensitive information using main in the middle attacks due to improper certificate validation. IBM X-Force ID: 189379.

IBM Concert 1.0.0 and 1.0.1 vulnerable to attacks that rely on the use of cookies without the SameSite attribute.

IBM QRadar SIEM 7.2.8 and 7.3 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. IBM X-force ID: 133120.

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.

Improper Certificate Validation vulnerability in Hitachi Infrastructure Analytics Advisor on Linux (Analytics probe component), Hitachi Ops Center Analyzer on Linux (Analyzer probe component) allows Man in the Middle Attack.This issue affects Hitachi Infrastructure Analytics Advisor: from 2.0.0-00 through 4.4.0-00; Hitachi Ops Center Analyzer: from 10.0.0-00 before 10.9.1-00.

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.

Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.

Improper certificate validation vulnerability in the LDAP utilities in Synology DiskStation Manager (DSM) before 7.1.1-42962-8, 7.2.1-69057-7 and 7.2.2-72806-3 allows man-in-the-middle attackers to hijack the authentication of administrators via unspecified vectors.

The Motorola MH702x devices, prior to version 2.0.0.301, do not properly verify the server certificate during communication with the support server which could lead to the communication channel being accessible by an attacker.

An improper certificate validation issue in Smartcard authentication in GitLab EE affecting all versions from 11.6 prior to 16.4.4, 16.5 prior to 16.5.4, and 16.6 prior to 16.6.2 allows an attacker to authenticate as another user given their public key if they use Smartcard authentication. Smartcard authentication is an experimental feature and has to be manually enabled by an administrator.

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,

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.

A vulnerability has been identified in SINEC INS (All versions < V1.0 SP2 Update 2). Affected products do not properly validate the certificate of the configured UMC server. This could allow an attacker to intercept credentials that are sent to the UMC server as well as to manipulate responses, potentially allowing an attacker to escalate privileges.

MiniTool Power Data Recovery 11.6 contains an insecure installation process that allows attackers to achieve remote code execution through a man in the middle attack.

BYD QIN PLUS DM-i Dilink OS v3.0_13.1.7.2204050.1 to v3.0_13.1.7.2312290.1_0 was discovered to cend broadcasts to the manufacturer's cloud server unencrypted, allowing attackers to execute a man-in-the-middle attack.

MiniTool Shadow Maker version 4.1 contains an insecure installation process that allows attackers to achieve remote code execution through a man in the middle attack.

MiniTool Partition Wizard 12.8 contains an insecure update mechanism that allows attackers to achieve remote code execution through a man in the middle attack.

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

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 vulnerability found in EdgeMAX EdgeRouter V2.0.9 and earlier could allow a malicious actor to execute a man-in-the-middle (MitM) attack during a firmware update. This vulnerability is fixed in EdgeMAX EdgeRouter V2.0.9-hotfix.1 and later.

Mattermost iOS app fails to properly validate the server certificate while initializing the TLS connection allowing a network attacker to intercept the WebSockets connection.

Dell PowerScale OneFS, versions 8.2.x-9.3.x, contains an Improper Certificate Validation vulnerability. An remote unauthenticated attacker could potentially exploit this vulnerability, leading to a full compromise of the system.

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.

An issue in the native clients for Amazon WorkSpaces (when running PCoIP protocol) may allow an attacker to access remote sessions via man-in-the-middle.

An issue in the native clients for Amazon WorkSpaces (when running Amazon DCV protocol), Amazon AppStream 2.0, and Amazon DCV Clients may allow an attacker to access remote sessions via man-in-the-middle.

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.

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.

A flaw was found in the openstack-tripleo-common component of the Red Hat OpenStack Platform (RHOSP) director. This vulnerability allows an attacker to deploy potentially compromised container images via disabling TLS certificate verification for registry mirrors, which could enable a man-in-the-middle (MITM) attack.

HTTP::Tiny before 0.083, a Perl core module since 5.13.9 and available standalone on CPAN, has an insecure default TLS configuration where users must opt in to verify certificates.

An improper certificate validation vulnerability was reported in LADM that could allow a network attacker with the ability to redirect an update request to a remote server and execute code with elevated privileges.

The Apache Pulsar C++ Client does not verify peer TLS certificates when making HTTPS calls for the OAuth2.0 Client Credential Flow, even when tlsAllowInsecureConnection is disabled via configuration. This vulnerability allows an attacker to perform a man in the middle attack and intercept and/or modify the GET request that is sent to the ClientCredentialFlow 'issuer url'. The intercepted credentials can be used to acquire authentication data from the OAuth2.0 server to then authenticate with an Apache Pulsar cluster. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack. The Apache Pulsar Python Client wraps the C++ client, so it is also vulnerable in the same way. This issue affects Apache Pulsar C++ Client and Python Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0 to 2.10.1; 2.6.4 and earlier. Any users running affected versions of the C++ Client or the Python Client should rotate vulnerable OAuth2.0 credentials, including client_id and client_secret. 2.7 C++ and Python Client users should upgrade to 2.7.5 and rotate vulnerable OAuth2.0 credentials. 2.8 C++ and Python Client users should upgrade to 2.8.4 and rotate vulnerable OAuth2.0 credentials. 2.9 C++ and Python Client users should upgrade to 2.9.3 and rotate vulnerable OAuth2.0 credentials. 2.10 C++ and Python Client users should upgrade to 2.10.2 and rotate vulnerable OAuth2.0 credentials. 3.0 C++ users are unaffected and 3.0 Python Client users will be unaffected when it is released. Any users running the C++ and Python Client for 2.6 or less should upgrade to one of the above patched versions.

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.

CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.

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.

Improper Certificate Validation in Samsung Email prior to version 6.1.82.0 allows remote attacker to intercept the network traffic including sensitive information.

AAn improper certificate validation vulnerability [CWE-295] in FortiClientWindows 7.2.0 through 7.2.2, 7.0.0 through 7.0.11, FortiClientLinux 7.2.0, 7.0.0 through 7.0.11 and FortiClientMac 7.0.0 through 7.0.11, 7.2.0 through 7.2.4 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the FortiGate and the FortiClient during the ZTNA tunnel creation

An Improper Certificate Validation vulnerability in LibreOffice existed where determining if a macro was signed by a trusted author was done by only matching the serial number and issuer string of the used certificate with that of a trusted certificate. This is not sufficient to verify that the macro was actually signed with the certificate. An adversary could therefore create an arbitrary certificate with a serial number and an issuer string identical to a trusted certificate which LibreOffice would present as belonging to the trusted author, potentially leading to the user to execute arbitrary code contained in macros improperly trusted. This issue affects: The Document Foundation LibreOffice 7.2 versions prior to 7.2.7; 7.3 versions prior to 7.3.1.

An improper certificate validation vulnerability [CWE-295] in FortiAnalyzer and FortiManager 7.2.0 through 7.2.1, 7.0.0 through 7.0.5, 6.4.8 through 6.4.10 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the device and the remote FortiGuard server hosting outbreakalert ressources.

A misconfiguration vulnerability exists in the urvpn_client functionality of Milesight UR32L v32.3.0.5. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.

When connecting to Amazon Workspaces, the SHA256 presented by AWS connection provisioner is not fully verified by Zero Clients. The issue could be exploited by an adversary that places a MITM (Man in the Middle) between a zero client and AWS session provisioner in the network. This issue is only applicable when connecting to an Amazon Workspace from a PCoIP Zero Client.

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

MiniTool Movie Maker 7.0 contains an insecure installation process that allows attackers to achieve remote code execution through a man in the middle attack.

Odyssey passes to server unencrypted bytes from man-in-the-middle When Odyssey is configured to use certificate Common Name for client authentication, a man-in-the-middle attacker can inject arbitrary SQL queries when a connection is first established, despite the use of SSL certificate verification and encryption. This is similar to CVE-2021-23214 for PostgreSQL.

MiniTool Partition Wizard 12.8 contains an insecure installation mechanism that allows attackers to achieve remote code execution through a man in the middle attack.