Total
1378 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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. | ||||
| 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-2025-40800 | 1 Siemens | 6 Comos, Nx, Simcenter 3d and 3 more | 2026-04-15 | 7.4 High |
| A vulnerability has been identified in COMOS V10.6 (All versions < V10.6.1), COMOS V10.6 (All versions < V10.6.1), NX V2412 (All versions < V2412.8700), NX V2506 (All versions < V2506.6000), Simcenter 3D (All versions < V2506.6000), Simcenter Femap (All versions < V2506.0002), Solid Edge SE2025 (All versions < V225.0 Update 10), Solid Edge SE2026 (All versions < V226.0 Update 1). The IAM client in affected products 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. | ||||
| CVE-2025-5279 | 2026-04-15 | 7.5 High | ||
| When the Amazon Redshift Python Connector is configured with the BrowserAzureOAuth2CredentialsProvider plugin, the driver skips the SSL certificate validation step for the Identity Provider. An insecure connection could allow an actor to intercept the token exchange process and retrieve an access token. This issue has been addressed in driver version 2.1.7. Users should upgrade to address this issue and ensure any forked or derivative code is patched to incorporate the new fixes. | ||||
| 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-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-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-34066 | 2026-04-15 | N/A | ||
| An improper certificate validation vulnerability exists in AVTECH IP cameras, DVRs, and NVRs due to the use of wget with --no-check-certificate in scripts like SyncCloudAccount.sh and SyncPermit.sh. This exposes HTTPS communications to man-in-the-middle (MITM) attacks. | ||||
| 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-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-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-4762 | 1 Lenovo | 2 Accessories And Display Manager, Display Control Center | 2026-04-15 | 7.8 High |
| An improper validation vulnerability was reported in the firmware update mechanism of LADM and LDCC that could allow a local attacker to escalate privileges. | ||||
| 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-2026-33896 | 1 Digitalbazaar | 1 Forge | 2026-04-14 | 7.4 High |
| 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. | ||||
| CVE-2026-32884 | 2 Botan Project, Randombit | 2 Botan, Botan | 2026-04-14 | 5.9 Medium |
| Botan is a C++ cryptography library. Prior to version 3.11.0, during processing of an X.509 certificate path using name constraints which restrict the set of allowable DNS names, if no subject alternative name is defined in the end-entity certificate Botan would check that the CN was allowed by the DNS name constraints, even though this check is technically not required by RFC 5280. However this check failed to account for the possibility of a mixed-case CN. Thus a certificate with CN=Sub.EVIL.COM and no subject alternative name would bypasses an excludedSubtrees constraint for evil.com because the comparison is case-sensitive. This issue has been patched in version 3.11.0. | ||||
| CVE-2026-34477 | 1 Apache | 1 Log4j | 2026-04-14 | 6.8 Medium |
| The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element. Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * An SMTP, Socket, or Syslog appender is in use. * TLS is configured via a nested <Ssl> element. * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. | ||||
| CVE-2026-0233 | 1 Palo Alto Networks | 1 Autonomous Digital Experience Manager | 2026-04-14 | N/A |
| A certificate validation vulnerability in Palo Alto Networks Autonomous Digital Experience Manager on Windows allows an unauthenticated attacker with adjacent network access to execute arbitrary code with NT AUTHORITY\SYSTEM privileges. | ||||
| CVE-2026-35207 | 1 Linuxdeepin | 2 Dde-control-center, Deepin-deepinid-plugin | 2026-04-13 | 5.4 Medium |
| dde-control-center is the control panel of DDE, the Deepin Desktop Environment. plugin-deepinid is a plugin in dde-control-center, which provides the deepinid cloud service. Prior to 6.1.80, plugin-deepinid is configured to skip TLS certificate verification when fetching the user's avatar from openapi.deepin.com or other providers. An MITM attacker could intercept the traffic, replace the avatar with a malicious or misleading image, and potentially identify the user by the avatar. This vulnerability is fixed in dde-control-center 6.1.80 and 5.9.9. | ||||
| CVE-2025-0239 | 2 Mozilla, Redhat | 8 Firefox, Thunderbird, Enterprise Linux and 5 more | 2026-04-13 | 4 Medium |
| When using Alt-Svc, ALPN did not properly validate certificates when the original server is redirecting to an insecure site. This vulnerability was fixed in Firefox 134, Firefox ESR 128.6, Thunderbird 134, and Thunderbird 128.6. | ||||
| CVE-2026-5263 | 1 Wolfssl | 1 Wolfssl | 2026-04-13 | N/A |
| URI nameConstraints from constrained intermediate CAs are parsed but not enforced during certificate chain verification in wolfcrypt/src/asn.c. A compromised or malicious sub-CA could issue leaf certificates with URI SAN entries that violate the nameConstraints of the issuing CA, and wolfSSL would accept them as valid. | ||||