| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode
is set.
Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.
RPKs are disabled by default in both TLS clients and TLS servers. The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain. The affected clients are those that then rely on the handshake to
fail when the server's RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.
Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected. This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.
The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. |
| 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. |
| 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. |
| The Infotainment ECU manufactured by Bosch which is installed in Nissan Leaf ZE1 – 2020 uses a Redbend service for over-the-air provisioning and updates. HTTPS is used for communication with the back-end server. Due to usage of the default configuration for the underlying SSL engine, the server root certificate is not verified. As a result, an attacker may be able to impersonate a Redbend backend server using a self-signed certificate.
First identified on Nissan Leaf ZE1 manufactured in 2020. |
| "This issue is limited to motherboards and does not affect laptops, desktop computers, or other endpoints." An insufficient validation vulnerability in ASUS DriverHub may allow untrusted sources to affect system behavior via crafted HTTP requests.
Refer to the 'Security Update for ASUS DriverHub' section on the ASUS Security Advisory for more information. |
| An issue was discovered on Alecto IVM-100 2019-11-12 devices. The device uses a custom UDP protocol to start and control video and audio services. The protocol has been partially reverse engineered. Based upon the reverse engineering, no password or username is ever transferred over this protocol. Thus, one can set up the camera connection feed with only the encoded UID. It is possible to set up sessions with the camera over the Internet by using the encoded UID and the custom UDP protocol, because authentication happens at the client side. |
| An Improper Certificate Validation vulnerability could allow an authenticated malicious actor with access to UniFi Protect Cameras adjacent network to make unsupported changes to the camera system. |
| A flaw was found in Podman. The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry. This issue results in a Man In The Middle attack. |
| 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. |
| KDE messagelib before 25.11.90 ignores SSL errors for threatMatches:find in the Google Safe Browsing Lookup API (aka phishing API), which might allow spoofing of threat data. NOTE: this Lookup API is not contacted in the messagelib default configuration. |
| 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). |
| A vulnerability has been identified within Rancher that can be exploited
in narrow circumstances through a man-in-the-middle (MITM) attack. An
attacker would need to have control of an expired domain or execute a
DNS spoofing/hijacking attack against the domain to exploit this
vulnerability. The targeted domain is the one used as the Rancher URL. |
| 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. |
| In Yealink RPS before 2025-05-26, the certificate upload function does not properly validate certificate content, potentially allowing invalid certificates to be uploaded. |
| Medixant RadiAnt DICOM Viewer is vulnerable due to failure of the update mechanism to verify the update server's certificate which could allow an attacker to alter network traffic and carry out a machine-in-the-middle attack (MITM). An attacker could modify the server's response and deliver a malicious update to the user. |
| 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. |
| An improper certificate validation vulnerability was reported in the Lenovo Universal Device Client (UDC) that could allow a user capable of intercepting network traffic to obtain application metadata, including device information, geolocation, and telemetry data. |
| BigFix Patch Download Plug-ins are affected by an insecure protocol support. The application can allow improper handling of SSL certificates validation. |
| 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. |
| A vulnerability has been identified in COMOS V10.6 (All versions < V10.6.1), COMOS V10.6 (All versions < V10.6.1), JT Bi-Directional Translator for STEP (All versions), NX V2412 (All versions < V2412.8900 with Cloud Entitlement (bundled as NX X)), NX V2506 (All versions < V2506.6000 with Cloud Entitlement (bundled as NX X)), Simcenter 3D (All versions < V2506.6000 with Cloud Entitlement (bundled as Simcenter X Mechanical)), Simcenter Femap (All versions < V2506.0002 with Cloud Entitlement (bundled as Simcenter X Mechanical)), Simcenter Studio (All versions < V2506.0001), Simcenter System Architect (All versions < V2506.0001), Tecnomatix Plant Simulation (All versions < V2504.0007). The SALT SDK is missing server certificate validation while establishing TLS connections to the authorization server. This could allow an attacker to perform a man-in-the-middle attack. |
