| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Improper Certificate Validation vulnerability exists in Tenable Security Center where an authenticated, privileged attacker could intercept email messages sent from Security Center via a rogue SMTP server. |
| An Improper Certificate Validation on UniFi OS devices, with Identity Enterprise configured, could allow a malicious actor to execute a man-in-the-middle (MitM) attack during application update. |
| NeuVector supports login authentication through OpenID Connect. However, the TLS verification (which verifies the remote server's authenticity and integrity) for OpenID Connect is not enforced by default. As a result this may expose the system to man-in-the-middle (MITM) attacks. |
| The server identity check mechanism for firmware upgrade performed via command shell is insecurely implemented potentially allowing an attacker to perform a Man-in-the-middle attack. This security issue has been fixed in the latest firmware version of Eaton G4 PDU which is available on the Eaton download center. |
| This vulnerability affects NeuVector deployments only when the Report anonymous cluster data option is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server.
In affected versions, NeuVector does not enforce TLS
certificate verification when transmitting anonymous cluster data to the
telemetry server. As a result, the communication channel is susceptible
to man-in-the-middle (MITM) attacks, where an attacker could intercept
or modify the transmitted data. Additionally, NeuVector loads the
response of the telemetry server is loaded into memory without size
limitation, which makes it vulnerable to a Denial of Service(DoS)
attack |
| GoSign Desktop through 2.4.1 disables TLS certificate validation when configured to use a proxy server. This can be problematic if the GoSign Desktop user selects an arbitrary proxy server without consideration of whether outbound HTTPS connections from the proxy server to Internet servers succeed even for untrusted or invalid server certificates. In this scenario (which is outside of the product's design objectives), integrity protection could be bypassed. In typical cases of a proxy server for outbound HTTPS traffic from an enterprise, those connections would not succeed. (Admittedly, the usual expectation is that a client application is configured to trust an enterprise CA and does not set SSL_VERIFY_NONE.) Also, it is of course unsafe to place ~/.gosign in the home directory of an untrusted user and then have other users execute downloaded files. |
| Akka.NET is a .NET port of the Akka project from the Scala / Java community. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. Those who run Akka.NET inside a private network that they fully control or who were never using TLS in the first place are now affected by the bug. However, those who use TLS to secure their networks must upgrade to Akka.NET V1.5.52 or later. One patch forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. The second patch, a critical fix, enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. As a workaround, avoid exposing the application publicly to avoid the vulnerability having a practical impact on one's application. However, upgrading to version 1.5.52 is still recommended by the maintainers. |
| TP-Link Tether versions prior to 4.5.13 and TP-Link Tapo versions prior to 3.3.6 do not properly validate certificates, which may allow a remote unauthenticated attacker to eavesdrop on an encrypted communication via a man-in-the-middle attack. |
| Collabora Online is a collaborative online office suite based on LibreOffice. In affected versions of Collabora Online, https connections from coolwsd to other hosts may incompletely verify the remote host's certificate's against the full chain of trust. This vulnerability is fixed in Collabora Online 24.04.4.3, 23.05.14.1, and 22.05.23.1. |
| In versions of the PEADM Forge Module prior to 3.24.0 a security misconfiguration was discovered. |
| Altair is a GraphQL client for all platforms. Prior to version 8.0.5, Altair GraphQL Client's desktop app does not validate HTTPS certificates allowing a man-in-the-middle to intercept all requests. Any Altair users on untrusted networks (eg. public wifi, malicious DNS servers) may have all GraphQL request and response headers and bodies fully compromised including authorization tokens. The attack also allows obtaining full access to any signed-in Altair GraphQL Cloud account and replacing payment checkout pages with a malicious website. Version 8.0.5 fixes the issue. |
| Improper Certificate Validation (CWE-295) in the Gallagher Milestone Integration Plugin (MIP) permits unauthenticated messages (e.g. alarm events) to be sent to the Plugin.
This issue effects Gallagher MIPS Plugin v4.0 prior to v4.0.32, all versions of v3.0 and prior. |
| An Improper Certificate Validation on the UniFi iOS App managing a standalone UniFi Access Point (not using UniFi Network Application) could allow a malicious actor with access to an adjacent network to take control of this UniFi Access Point.
Affected Products:
UniFi iOS App (Version 10.17.7 and earlier)
Mitigation:
UniFi iOS App (Version 10.18.0 or later). |
| An issue in Eugeny Tabby 1.0.213 allows a remote attacker to obtain sensitive information via the server and sends the SSH username and password even when the host key verification fails. |
| Improper certificate validation vulnerability exists in 'デジラアプリ' App for iOS prior to ver.80.10.00. If this vulnerability is exploited, a man-in-the-middle attack may allow an attacker to eavesdrop on and/or tamper with an encrypted communication. |
| go-witness and witness are Go modules for generating attestations. In go-witness versions 0.8.6 and earlier and witness versions 0.9.2 and earlier the AWS attestor improperly verifies AWS EC2 instance identity documents. Verification can incorrectly succeed when a signature is not present or is empty, and when RSA signature verification fails. The attestor also embeds a single legacy global AWS public certificate and does not account for newer region specific certificates issued in 2024, making detection of forged documents difficult without additional trusted region data. An attacker able to supply or intercept instance identity document data (such as through Instance Metadata Service impersonation) can cause a forged identity document to be accepted, leading to incorrect trust decisions based on the attestation. This is fixed in go-witness 0.9.1 and witness 0.10.1. As a workaround, manually verify the included identity document, signature, and public key with standard tools (for example openssl) following AWS’s verification guidance, or disable use of the AWS attestor until upgraded. |
| A flaw was found in libnbd. The client did not always correctly verify the NBD server's certificate when using TLS to connect to an NBD server. This issue allows a man-in-the-middle attack on NBD traffic. |
| Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon. |
| A vulnerability was reported in the Lenovo Scanner pro application during an internal security assessment that, under certain circumstances, could allow an attacker on the same logical network to disclose sensitive user files from the application. |
| A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation. |
