Export limit exceeded: 409000 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3047 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-36754 | 1 Growatt | 1 Shinelan-x | 2026-04-15 | N/A |
| The authentication mechanism on web interface is not properly implemented. It is possible to bypass authentication checks by crafting a post request with new settings since there is no session token or authentication in place. This would allow an attacker for instance to point the device to an arbitrary address for domain name resolution to e.g. facililitate a man-in-the-middle (MitM) attack. | ||||
| CVE-2025-48027 | 2026-04-15 | 5.4 Medium | ||
| The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver. | ||||
| CVE-2024-36557 | 2026-04-15 | 6.6 Medium | ||
| The device ID is based on IMEI in Forever KidsWatch Call Me KW50 R36_YDR_A3PW_GM7S_V1.0_2019_07_15_16.19.24_cob_h and Forever KidsWatch Call Me 2 KW60 R36CW_YDE_S4_A29_2_V1.0_2023.05.24_22.49.44_cob_b. If a malicious user changes the IMEI to the IMEI of a unit they registered in the mobile app, it is possible to hijack the device and control it from the app. | ||||
| CVE-2024-47258 | 2026-04-15 | 8.1 High | ||
| 2N Access Commander version 2.1 and prior is vulnerable in default settings to Man In The Middle attack due to not verifying certificates of 2N edge devices. 2N has currently released an updated version 3.3 of 2N Access Commander, with added Certificate Fingerprint Verification. Since version 2.2 of 2N Access Commander (released in February 2022) it is also possible to enforce TLS certificate validation.It is recommended that all customers update 2N Access Commander to the latest version and use one of two mentioned practices. | ||||
| 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-22874 | 2026-04-15 | 7.5 High | ||
| 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. | ||||
| CVE-2025-7390 | 1 Softing | 4 Edgeaggregator, Edgeconnector, Opc and 1 more | 2026-04-15 | 9.1 Critical |
| A malicious client can bypass the client certificate trust check of an opc.https server when the server endpoint is configured to allow only secure communication. | ||||
| CVE-2025-7448 | 1 Silabs | 1 Wi-sun Stack | 2026-04-15 | N/A |
| Wi-SUN unexpected 4- Way Handshake packet receptions may lead to predictable keys and potentially leading to Man in the middle (MitM) attack | ||||
| CVE-2025-53869 | 1 Brother | 1 Multiple Mfps | 2026-04-15 | 3.7 Low |
| Multiple MFPs provided by Brother Industries, Ltd. does not properly validate server certificates, which may allow a man-in-the-middle attacker to replace the set of root certificates used by the product with a set of arbitrary certificates. | ||||
| 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-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-2025-12790 | 1 Redhat | 1 Satellite | 2026-04-15 | 7.4 High |
| A flaw was found in Rubygem MQTT. By default, the package used to not have hostname validation, resulting in possible Man-in-the-Middle (MITM) attack. | ||||
| CVE-2025-60022 | 2026-04-15 | N/A | ||
| 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. | ||||
| CVE-2025-7395 | 1 Wolfssl | 1 Wolfssl | 2026-04-15 | N/A |
| A certificate verification error in wolfSSL when building with the WOLFSSL_SYS_CA_CERTS and WOLFSSL_APPLE_NATIVE_CERT_VALIDATION options results in the wolfSSL client failing to properly verify the server certificate's domain name, allowing any certificate issued by a trusted CA to be accepted regardless of the hostname. | ||||
| CVE-2024-49214 | 1 Haproxy | 1 Haproxy | 2026-04-15 | 5.3 Medium |
| QUIC in HAProxy 3.1.x before 3.1-dev7, 3.0.x before 3.0.5, and 2.9.x before 2.9.11 allows opening a 0-RTT session with a spoofed IP address. This can bypass the IP allow/block list functionality. | ||||
| CVE-2025-9265 | 1 Kiloview | 1 Ndi N30 | 2026-04-15 | N/A |
| A broken authorization vulnerability in Kiloview NDI N30 allows a remote unauthenticated attacker to deactivate user verification, giving them access to state changing actions that should only be initiated by administratorsThis issue affects Kiloview NDI N30 and was fixed in Firmware version later than 2.02.0246 | ||||
| CVE-2024-7957 | 1 Danswer-ai | 1 Danswer | 2026-04-15 | N/A |
| An arbitrary file overwrite vulnerability exists in the ZulipConnector of danswer-ai/danswer, affecting the latest version. The vulnerability arises from the load_credentials method, where user-controlled input for realm_name and zuliprc_content is used to construct file paths and write file contents. This allows attackers to overwrite or create arbitrary files if a zuliprc- directory already exists in the temporary directory. | ||||
| CVE-2021-27289 | 2026-04-15 | 9.1 Critical | ||
| A replay attack vulnerability was discovered in a Zigbee smart home kit manufactured by Ksix (Zigbee Gateway Module = v1.0.3, Door Sensor = v1.0.7, Motion Sensor = v1.0.12), where the Zigbee anti-replay mechanism - based on the frame counter field - is improperly implemented. As a result, an attacker within wireless range can resend captured packets with a higher sequence number, which the devices incorrectly accept as legitimate messages. This allows spoofed commands to be injected without authentication, triggering false alerts and misleading the user through notifications in the mobile application used to monitor the network. | ||||
| 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. | ||||
| CVE-2024-12797 | 1 Redhat | 5 Discovery, Enterprise Linux, Logging and 2 more | 2026-04-15 | 6.3 Medium |
| 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. | ||||