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.

An improper certificate validation vulnerability [CWE-295] in FortiPortal version 7.4.0, version 7.2.4 and below, version 7.0.8 and below, version 6.0.15 and below when connecting to a FortiManager device, a FortiAnalyzer device, or an SMTP server may allow an unauthenticated attacker in a Man-in-the-Middle position to intercept on and tamper with the encrypted communication channel established between the FortiPortal and those endpoints.

An improper certificate validation vulnerability [CWE-295] in FortiWeb 7.2.0 through 7.2.1, 7.0 all versions, 6.4 all versions and 6.3 all versions may allow a remote and unauthenticated attacker in a Man-in-the-Middle position to decipher and/or tamper with the communication channel between the device and different endpoints used to fetch data for Web Application Firewall (WAF).

An improper certificate validation vulnerability [CWE-295] in FortiADC 7.4.0, 7.2.0 through 7.2.3, 7.1 all versions, 7.0 all versions, 6.2 all versions, 6.1 all versions and 6.0 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the device and various remote servers such as private SDN connectors and FortiToken Cloud.

An improper certificate validation vulnerability [CWE-295] in FortiADC 7.4.0, 7.2 all versions, 7.1 all versions, 7.0 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the device and public SDN connectors.

An improper certificate validation vulnerability [CWE-295] in FortiNAC-F version 7.2.4 and below may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the HTTPS communication channel between the FortiOS device, an inventory, and FortiNAC-F.

An improper certificate validation vulnerability in Fortinet FortiOS 7.4.0 through 7.4.1, FortiOS 7.2.0 through 7.2.6, FortiOS 7.0.0 through 7.0.15, FortiOS 6.4 all versions allows a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the FortiLink communication channel between the FortiOS device and FortiSwitch.

An improper certificate validation vulnerability [CWE-295] in FortiOS 6.2 all versions, 6.4 all versions, 7.0.0 through 7.0.10, 7.2.0 and FortiProxy 1.2 all versions, 2.0 all versions, 7.0.0 through 7.0.9, 7.2.0 through 7.2.3 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the vulnerable device and the remote FortiGuard's map server.

A use of a weak cryptographic algorithm vulnerability [CWE-327] in FortiNAC 9.4.1 and below, 9.2.6 and below, 9.1.0 all versions, 8.8.0 all versions, 8.7.0 all versions may increase the chances of an attacker to have access to sensitive information or to perform man-in-the-middle attacks.

Some cryptographic issues in Fortinet FortiNAC versions 9.4.0 through 9.4.1, 9.2.0 through 9.2.7, 9.1.0 through 9.1.8, 8.8.0 through 8.8.11, 8.7.0 through 8.7.6, 8.6.0 through 8.6.5, 8.5.0 through 8.5.4, 8.3.7 may allow an attacker to decrypt and forge protocol communication messages.

An Insufficient Session Expiration vulnerability [CWE-613] in FortiOS SSL-VPN version 7.6.0, version 7.4.6 and below, version 7.2.10 and below, 7.0 all versions, 6.4 all versions may allow an attacker in possession of a cookie used to log in the SSL-VPN portal to log in again, although the session has expired or was logged out.

An Insufficient Session Expiration vulnerability [CWE-613] in FortiOS SSL VPN 7.6.0 through 7.6.2, 7.4.0 through 7.4.6, 7.2.0 through 7.2.10, 7.0.0 through 7.0.16, 6.4 all versions may allow a remote attacker (e.g. a former admin whose account was removed and whose session was terminated) in possession of the SAML record of a user session to access or re-open that session via re-use of SAML record.

A improper validation of certificate with host mismatch in Fortinet FortiClientWindows version 7.4.0, versions 7.2.0 through 7.2.6, and 7.0 all versions allow an unauthorized attacker to redirect VPN connections via DNS spoofing or another form of redirection.

An improper following of a certificate's chain of trust vulnerability in FortiGate versions 6.4.0 to 6.4.4 may allow an LDAP user to connect to SSLVPN with any certificate that is signed by a trusted Certificate Authority.

An improper certificate validation vulnerability [CWE-295] in FortiOS 6.0.0 through 6.0.14, 6.2.0 through 6.2.10, 6.4.0 through 6.4.8, 7.0.0 may allow a network adjacent and unauthenticated attacker to man-in-the-middle the communication between the FortiGate and some peers such as private SDNs and external cloud platforms.

An improper certificate validation vulnerability [CWE-295] in FortiManager 7.0.1 and below, 6.4.6 and below; FortiAnalyzer 7.0.2 and below, 6.4.7 and below; FortiOS 6.2.x and 6.0.x; FortiSandbox 4.0.x, 3.2.x and 3.1.x may allow a network adjacent and unauthenticated attacker to man-in-the-middle the communication between the listed products and some external peers.

A combination of a use of hard-coded cryptographic key vulnerability [CWE-321] in FortiClientEMS 7.0.1 and below, 6.4.6 and below and an improper certificate validation vulnerability [CWE-297] in FortiClientWindows, FortiClientLinux and FortiClientMac 7.0.1 and below, 6.4.6 and below may allow an unauthenticated and network adjacent attacker to perform a man-in-the-middle attack between the EMS and the FCT via the telemetry protocol.

A improper certificate validation vulnerability in Fortinet FortiAnalyzer 7.6.0 through 7.6.4, FortiAnalyzer 7.4.0 through 7.4.8, FortiAnalyzer 7.2 all versions, FortiAnalyzer 7.0 all versions, FortiAnalyzer 6.4 all versions, FortiManager 7.6.0 through 7.6.4, FortiManager 7.4.0 through 7.4.8, FortiManager 7.2 all versions, FortiManager 7.0 all versions, FortiManager 6.4 all versions may allow a remote unauthenticated attacker to view confidential information via a man in the middle [MiTM] attack.

A improper validation of certificate with host mismatch in Fortinet FortiTokenAndroid version 5.0.3 and below, Fortinet FortiTokeniOS version 5.2.0 and below, Fortinet FortiTokenWinApp version 4.0.3 and below allows attacker to retrieve information disclosed via man-in-the-middle attacks.

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 [CWE-295] in FortiOS version 7.6.1 and below, version 7.4.7 and below may allow an EAP verified remote user to connect from FortiClient via revoked certificate.

The default configuration of Fortinet Fortigate UTM appliances uses the same Certification Authority certificate and same private key across different customers' installations, which makes it easier for man-in-the-middle attackers to spoof SSL servers by leveraging the presence of the Fortinet_CA_SSLProxy certificate in a list of trusted root certification authorities.

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.

An improper validation of certificate with host mismatch [CWE-297] vulnerability in FortiOS versions 6.4.6 and below may allow the connection to a malicious LDAP server via options in GUI, leading to disclosure of sensitive information, such as AD credentials.

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows OCSP designated-responder authorization bypass via missing signature verification. The OCSP response validation in public_key:pkix_ocsp_validate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid. This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the public_key:pkix_ocsp_validate/5 API directly are also affected, with impact depending on usage context. This vulnerability is associated with program files lib/public_key/src/pubkey_ocsp.erl and program routines pubkey_ocsp:is_authorized_responder/3. This issue affects OTP from OTP 27.0 until OTP 28.4.2 and 27.3.4.10 corresponding to public_key from 1.16 until 1.20.3 and 1.17.1.2, and ssl from 11.2 until 11.5.4 and 11.2.12.7.

core/imap/MCIMAPSession.cpp in Canary Mail before 3.22 has Missing SSL Certificate Validation for IMAP in STARTTLS mode.

A vulnerability has been identified in SINUMERIK Analyse MyCondition (All versions), SINUMERIK Analyze MyPerformance (All versions), SINUMERIK Analyze MyPerformance /OEE-Monitor (All versions), SINUMERIK Analyze MyPerformance /OEE-Tuning (All versions), SINUMERIK Integrate Client 02 (All versions >= V02.00.12 < 02.00.18), SINUMERIK Integrate Client 03 (All versions >= V03.00.12 < 03.00.18), SINUMERIK Integrate Client 04 (V04.00.02 and all versions >= V04.00.15 < 04.00.18), SINUMERIK Integrate for Production 4.1 (All versions < V4.1 SP10 HF3), SINUMERIK Integrate for Production 5.1 (V5.1), SINUMERIK Manage MyMachines (All versions), SINUMERIK Manage MyMachines /Remote (All versions), SINUMERIK Manage MyMachines /Spindel Monitor (All versions), SINUMERIK Manage MyPrograms (All versions), SINUMERIK Manage MyResources /Programs (All versions), SINUMERIK Manage MyResources /Tools (All versions), SINUMERIK Manage MyTools (All versions), SINUMERIK Operate V4.8 (All versions < V4.8 SP8), SINUMERIK Operate V4.93 (All versions < V4.93 HF7), SINUMERIK Operate V4.94 (All versions < V4.94 HF5), SINUMERIK Optimize MyProgramming /NX-Cam Editor (All versions). Due to an error in a third-party dependency the ssl flags used for setting up a TLS connection to a server are overwitten with wrong settings. This results in a missing validation of the server certificate and thus in a possible TLS MITM szenario.

Improper certificate validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remote unauthenticated attacker to enroll a device belonging to a restricted set of unenrolled devices, leading to information disclosure about EPMM appliance and impacting on the integrity of the newly enrolled device identity.

Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It's important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.

Jenkins Bitbucket Push and Pull Request Plugin 3.3.8 and earlier unconditionally disables SSL/TLS certificate and hostname validation for connections sending Bearer token authenticated requests to the configured Bitbucket Server endpoint, allowing attackers able to intercept network traffic to capture the token.

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.

FastNetMon Community Edition through 1.2.9 does not verify TLS certificates on outbound HTTPS connections. The execute_web_request_secure() function in src/fast_library.cpp creates a boost::asio::ssl::context with tls_client mode and calls set_default_verify_paths() to load CA certificates, but never calls set_verify_mode(boost::asio::ssl::verify_peer). Without this call, OpenSSL performs the TLS handshake without validating the server's certificate chain, making all HTTPS connections vulnerable to man-in-the-middle attacks. This function is used for telemetry reporting to community-stats.fastnetmon.com, which sends system information including CPU model, kernel version, traffic statistics, and software configuration. An attacker can intercept and modify this data or redirect it to a malicious server.

A weakness in the certificate validation logic of the deprecated IKEv1 key exchange may allow an unauthenticated attacker positioned as a man-in-the-middle to bypass certificate validation in VPN site-to-site connections that use certificate-based authentication. Successful exploitation could allow interception or modification of traffic traversing the VPN tunnel.

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.

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.

The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. 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.

Missing SSL Certificate Validation issue exists in Pluck 4.7.15 in update_applet.php, which could lead to man-in-the-middle attacks.

Windows Secure Channel Spoofing Vulnerability

An Improper Certificate Validation vulnerability in the OPC-UA client and ANSL over TLS client used in Automation Studio versions before 6.5 could allow an unauthenticated attacker on the network to position themselves to intercept and interfere with data exchanges.

A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.

Improper Certificate Validation in Checkmk Exchange plugin MikroTik allows attackers in MitM position to intercept traffic. This issue affects MikroTik: from 2.0.0 through 2.5.5, from 0.4a_mk through 2.0a.

Impact: undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings. Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange. Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added. Patches: Upgrade to undici v7.28.0 or v8.5.0. Workarounds: No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly.

aria2c accepts a server certificate with incorrect Extended Key Usage (EKU). If the attackers compromise a certificate (with the associated private key) issued for a different purpose, they may be able to reuse it for TLS server authentication.

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.

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 flaw was found in assisted-migration-agent. The application hardcodes insecure Transport Layer Security (TLS) connections when communicating with vCenter. This vulnerability allows a Man-in-the-Middle (MITM) attacker to intercept and harvest vCenter administrator credentials. This can lead to unauthorized access to vCenter.

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.

A vulnerability in the certificate validation of Cisco&nbsp;Expressway-C and Cisco&nbsp;TelePresence VCS could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data.&nbsp;&nbsp;The vulnerability is due to a lack of validation of the SSL server certificate that an affected device receives when it establishes a connection to a Cisco&nbsp;Unified Communications Manager device. An attacker could exploit this vulnerability by using a man-in-the-middle technique to intercept the traffic between the devices, and then using a self-signed certificate to impersonate the endpoint. A successful exploit could allow the attacker to view the intercepted traffic in clear text or alter the contents of the traffic. Note: Cisco&nbsp;Expressway-E is not affected by this vulnerability.Cisco&nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

In OCaml-TLS before 2.1.0, the server implementation does insufficient checks of the certificate provided by the client (when doing client authentication), which allows impersonation with certificates that are not meant for client authentication (because of KeyUsage and ExtendedKeyUsage).

Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice. This issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0. Users are recommended to upgrade to version 1.12.0, which fixes the issue.