nginx http proxy module does not verify peer identity of https origin server which could facilitate man-in-the-middle attack (MITM)

F5 BIG-IP 15.0.0, 14.1.0-14.1.0.6, 14.0.0-14.0.0.5, 13.0.0-13.1.1.5, 12.1.0-12.1.4.1, 11.6.0-11.6.4, and 11.5.1-11.5.9 and Enterprise Manager 3.1.1 may expose sensitive information and allow the system configuration to be modified when using non-default ConfigSync settings.

F5 BIG-IP ASM 15.0.0, 14.1.0-14.1.0.6, 14.0.0-14.0.0.5, 13.0.0-13.1.1.5, 12.1.0-12.1.4.1, 11.6.0-11.6.4, and 11.5.1-11.5.9 may expose sensitive information and allow the system configuration to be modified when using non-default settings.

On all versions of BIG-IP 12.1.x and 11.6.x, the original TLS protocol includes a weakness in the master secret negotiation that is mitigated by the Extended Master Secret (EMS) extension defined in RFC 7627. TLS connections that do not use EMS are vulnerable to man-in-the-middle attacks during renegotiation. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.

On all 7.x and 6.x versions (fixed in 8.0.0), when using a Quorum device for BIG-IQ high availability (HA) for automatic failover, BIG-IQ does not make use of Transport Layer Security (TLS) with the Corosync protocol. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.

On versions 15.1.0-15.1.0.1, 15.0.0-15.0.1.2, and 14.1.0-14.1.2.3, BIG-IP Virtual Edition (VE) may expose a mechanism for remote attackers to access local daemons and bypass port lockdown settings.

In BIG-IQ 5.2.0-7.0.0, high availability (HA) synchronization is not secure by TLS and may allow on-path attackers to read / modify confidential data in transit.

In versions prior to 3.3.0, the NGINX Controller is configured to communicate with its Postgres database server over unencrypted channels, making the communicated data vulnerable to interception via man-in-the-middle (MiTM) attacks.

On versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.3, and 12.1.0-12.1.5.1, BIG-IP systems set up for connection mirroring in a high availability (HA) pair transfer sensitive cryptographic objects over an insecure communications channel. This is a control plane issue which is exposed only on the network used for connection mirroring.

On versions 15.0.0-15.1.0.3, 14.1.0-14.1.2.4, 13.1.0-13.1.3.3, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.1, the default deployment mode for BIG-IP high availability (HA) pair mirroring is insecure. This is a control plane issue that is exposed only on the network used for mirroring.

On versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.3, and 12.1.0-12.1.5.1, BIG-IP systems setup for connection mirroring in a High Availability (HA) pair transfers sensitive cryptographic objects over an insecure communications channel. This is a control plane issue which is exposed only on the network used for connection mirroring.

On F5 BIG-IP versions 13.0.0 - 13.1.0.3, attackers may be able to disrupt services on the BIG-IP system with maliciously crafted client certificate. This vulnerability affects virtual servers associated with Client SSL profile which enables the use of client certificate authentication. Client certificate authentication is not enabled by default in Client SSL profile. There is no control plane exposure.

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

In some situations on BIG-IP APM 14.0.0-14.0.0.2, 13.0.0-13.1.0.7, 12.1.0-12.1.3.5, or 11.6.0-11.6.3.2, the CRLDP Auth access policy agent may treat revoked certificates as valid when the BIG-IP APM system fails to download a new Certificate Revocation List.

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

An improper certificate validation vulnerability exists in BIG-IP Next Central Manager and may allow an attacker to impersonate an Instance Provider system.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

On BIG-IP 14.1.0-14.1.0.1, TMM may restart and produce a core file when validating SSL certificates in client SSL or server SSL profiles.

On versions 15.0.0-15.0.1.1, the BIG-IP ASM Cloud Security Services profile uses a built-in verification mechanism that fails to properly authenticate the X.509 certificate of remote endpoints.

F5 Access for Android before version 3.1.2 which uses HTTPS does not verify the remote endpoint identity. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

An improper certificate validation vulnerability exists in the BIG-IP Edge Client for Windows and macOS and may allow an attacker to impersonate a BIG-IP APM system.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

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.

Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack.

In versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.4, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.2, the BIG-IP Client or Server SSL profile ignores revoked certificates, even when a valid CRL is present. This impacts SSL/TLS connections and may result in a man-in-the-middle attack on the connections.

In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.

Apache Thrift Java client library versions 0.5.0 through 0.11.0 can bypass SASL negotiation isComplete validation in the org.apache.thrift.transport.TSaslTransport class. An assert used to determine if the SASL handshake had successfully completed could be disabled in production settings making the validation incomplete.

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.

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.

X509 certificate verification was not correctly implemented in the IP Intelligence Subscription and IP Intelligence feed-list features, and thus the remote server's identity is not properly validated in F5 BIG-IP 12.0.0-12.1.2, 11.6.0-11.6.2, or 11.5.0-11.5.5.

In Botan before 2.19.3, it is possible to forge OCSP responses due to a certificate verification error. This issue was introduced in Botan 1.11.34 (November 2016).

Missing hash/digest size and OID checks allow digests smaller than allowed when verifying ECDSA certificates, or smaller than is appropriate for the relevant key type, to be accepted by signature verification functions. This could lead to reduced security of ECDSA certificate-based authentication if the public CA key used is also known. This affects ECDSA/ECC verification when EdDSA or ML-DSA is also enabled.

Taipower APP for Andorid developed by Taipower has an Improper Certificate Validation vulnerability. When establishing an HTTPS connection with the server, the application fails to verify the server-side TLS/SSL certificate. This flaw allows an unauthenticated remote attackers to exploit the vulnerability to perform a Man-in-the-Middle (MITM) attack to read and tamper with network packets.

Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, `pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid. Version 1.4.0 patches the issue.

Incus is a system container and virtual machine manager. Prior to version 6.23.0, a lack of validation of the image fingerprint when downloading from simplestreams image servers opens the door to image cache poisoning and under very narrow circumstances exposes other tenants to running attacker controlled images rather than the expected one. Version 6.23.0 patches the issue.

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.

Starting with diego-release 2.55.0 and up to 2.69.0, and starting with CF Deployment 17.1 and up to 23.2.0, apps are accessible via another port on diego cells, allowing application ingress without a client certificate. If mTLS route integrity is enabled AND unproxied ports are turned off, then an attacker could connect to an application that should be only reachable via mTLS, without presenting a client certificate.

Wazuh provisioning scripts and Dockerfiles contain an insecure transport vulnerability where curl is invoked with the -k/--insecure flag, disabling SSL/TLS certificate validation. Attackers with network access can perform man-in-the-middle attacks to intercept and modify downloaded dependencies or code during the build process, leading to remote code execution and supply chain compromise.

fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection.

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

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 client applications in 3CX on Windows, the 3CX app for iOS, and the 3CX application for Android through 2022-03-17 lack SSL certificate validation.

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.

Precision Bridge PrecisionBridge.exe (aka the thick client) before 7.3.21 allows an integrity violation in which the same license key is used on multiple systems, via vectors involving a Process Hacker memory dump, error message inspection, and modification of a MAC address.

Icinga 2 v2.8.0 through v2.11.7 and v2.12.2 has an issue where revoked certificates due for renewal will automatically be renewed, ignoring the CRL. This issue is fixed in Icinga 2 v2.11.8 and v2.12.3.

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.

Alist is a file list program that supports multiple storages, powered by Gin and Solidjs. Prior to version 3.57.0, the application disables TLS certificate verification by default for all outgoing storage driver communications, making the system vulnerable to Man-in-the-Middle (MitM) attacks. This enables the complete decryption, theft, and manipulation of all data transmitted during storage operations, severely compromising the confidentiality and integrity of user data. This issue has been patched in version 3.57.0.

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.

Jenkins Mailer Plugin 1.32 and earlier does not perform hostname validation when connecting to the configured SMTP server.

Jenkins Email Extension Plugin 2.75 and earlier does not perform hostname validation when connecting to the configured SMTP server.

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.