Search Results (1434 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2025-70043 1 Ayms 1 Node-to 2026-04-15 9.1 Critical
An issue pertaining to CWE-295: Improper Certificate Validation was discovered in Ayms node-To master. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in TLS socket options
CVE-2025-0309 1 Netskope 1 Netskope 2026-04-15 N/A
An insufficient validation on the server connection endpoint in Netskope Client allows local users to elevate privileges on the system. The insufficient validation allows Netskope Client to connect to any other server with Public Signed CA TLS certificates and send specially crafted responses to elevate privileges.
CVE-2024-22030 1 Suse 1 Rancher 2026-04-15 8 High
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.
CVE-2024-13956 1 Abb 3 Aspect Enterprise, Matrix Series, Nexus Series 2026-04-15 6.7 Medium
SSL Verification Bypass vulnerabilities exist in ASPECT if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*.
CVE-2025-2183 1 Palo Alto Networks 1 Globalprotect App 2026-04-15 N/A
An insufficient certificate validation issue in the Palo Alto Networks GlobalProtect™ app enables attackers to connect the GlobalProtect app to arbitrary servers. This can enable a local non-administrative operating system user or an attacker on the same subnet to install malicious root certificates on the endpoint and subsequently install malicious software signed by the malicious root certificates on that endpoint.
CVE-2025-15573 2 Solax, Solax Power 5 Pocket Wifi 3, Pocket Wifi+4gm, Pocket Wifi+lan and 2 more 2026-04-15 9.4 Critical
The affected devices do not validate the server certificate when connecting to the SolaX Cloud MQTTS server hosted in the Alibaba Cloud (mqtt001.solaxcloud.com, TCP 8883). This allows attackers in a man-in-the-middle position to act as the legitimate MQTT server and issue arbitrary commands to devices.
CVE-2025-58781 2026-04-15 N/A
WTW-EAGLE App does not properly validate server certificates, which may allow a man-in-the-middle attacker to monitor encrypted traffic.
CVE-2025-0254 2026-04-15 5.9 Medium
HCL Digital Experience components Ring API and dxclient may be vulnerable to man-in-the-middle (MitM) attacks prior to 9.5 CF226. An attacker could intercept and potentially alter communication between two parties.
CVE-2025-10548 1 Clevercontrol 1 Clevercontrol 2026-04-15 6.5 Medium
The CleverControl employee monitoring software (v11.5.1041.6) fails to validate TLS server certificates during the installation process. The installer downloads and executes external components using curl.exe --insecure, enabling a man-in-the-middle attacker to deliver malicious files that are executed with SYSTEM privileges. This can lead to full remote code execution with administrative rights. No patch is available as the vendor has been unresponsive. It is assumed that previous versions are also affected, but this is not confirmed.
CVE-2024-13990 1 Microworld Technologies 1 Escan 2026-04-15 N/A
MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then.
CVE-2025-69412 1 Kde 1 Messagelib 2026-04-15 3.4 Low
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.
CVE-2025-23114 2026-04-15 N/A
A vulnerability in Veeam Updater component allows Man-in-the-Middle attackers to execute arbitrary code on the affected server. This issue occurs due to a failure to properly validate TLS certificate.
CVE-2025-23091 2026-04-15 N/A
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.
CVE-2025-23118 2026-04-15 N/A
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.
CVE-2024-7206 2026-04-15 N/A
SSL Pinning Bypass in eWeLink Some hardware products allows local ATTACKER to Decrypt TLS communication and Extract secrets to clone the device via Flash the modified firmware
CVE-2024-6001 1 Lenovo 1 Accessories And Display Manager 2026-04-15 8.1 High
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.
CVE-2025-66001 1 Suse 1 Neuvector 2026-04-15 8.8 High
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.
CVE-2025-62375 1 Go-witness 1 Go-witness 2026-04-15 5.9 Medium
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.
CVE-2025-30000 2026-04-15 6.7 Medium
A vulnerability has been identified in Siemens License Server (SLS) (All versions < V4.3). The affected application does not properly restrict permissions of the users. This could allow a lowly-privileged attacker to escalate their privileges.
CVE-2025-61778 1 Akkadotnet 1 Akka.net 2026-04-15 N/A
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.