Total
1402 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-65753 | 2026-06-17 | N/A | 7.5 HIGH | ||
| An issue in the TLS certification mechanism of Guardian Gryphon v01.06.0006.22 allows attackers to execute commands as root. | |||||
| CVE-2025-65291 | 1 Aqara | 6 Camera Hub G3, Camera Hub G3 Firmware, Hub M2 and 3 more | 2026-06-17 | N/A | 7.4 HIGH |
| Aqara Hub devices including Hub M2 4.3.6_0027, Hub M3 4.3.6_0025, Camera Hub G3 4.1.9_0027 fail to validate server certificates in TLS connections for discovery services and CoAP gateway communications, enabling man-in-the-middle attacks on device control and monitoring. | |||||
| CVE-2025-65290 | 1 Aqara | 6 Camera Hub G3, Camera Hub G3 Firmware, Hub M2 and 3 more | 2026-06-17 | N/A | 7.4 HIGH |
| Aqara Hub devices including Camera Hub G3 4.1.9_0027, Hub M2 4.3.6_0027, and Hub M3 4.3.6_0025 fail to validate server certificates during HTTPS firmware downloads, allowing man-in-the-middle attackers to intercept firmware update traffic and potentially serve modified firmware files. | |||||
| CVE-2025-65083 | 2026-06-17 | N/A | 3.2 LOW | ||
| 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. | |||||
| CVE-2025-64685 | 1 Jetbrains | 1 Youtrack | 2026-06-17 | N/A | 8.1 HIGH |
| In JetBrains YouTrack before 2025.3.104432 missing TLS certificate validation enabled data disclosure | |||||
| CVE-2025-64432 | 1 Kubevirt | 1 Kubevirt | 2026-06-17 | N/A | 4.7 MEDIUM |
| KubeVirt is a virtual machine management add-on for Kubernetes. Versions 1.5.3 and below, and 1.6.0 contained a flawed implementation of the Kubernetes aggregation layer's authentication flow which could enable bypass of RBAC controls. It was discovered that the virt-api component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the extension-apiserver-authentication configmap. Failre to validate certain fields in the client TLS certificate may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component. This issue is fixed in versions 1.5.3 and 1.6.1. | |||||
| CVE-2025-62375 | 2026-06-17 | N/A | N/A | ||
| 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-62371 | 1 Amazon | 1 Opensearch Data Prepper | 2026-06-17 | N/A | 7.4 HIGH |
| OpenSearch Data Prepper as an open source data collector for observability data. In versions prior to 2.12.2, the OpenSearch sink and source plugins in Data Prepper trust all SSL certificates by default when no certificate path is provided. Prior to this fix, the OpenSearch sink and source plugins would automatically use a trust all SSL strategy when connecting to OpenSearch clusters if no certificate path was explicitly configured. This behavior bypasses SSL certificate validation, potentially allowing attackers to intercept and modify data in transit through man-in-the-middle attacks. The vulnerability affects connections to OpenSearch when the cert parameter is not explicitly provided. This issue has been patched in version 2.12.2. As a workaround, users can add the cert parameter to their OpenSearch sink or source configuration with the path to the cluster's CA certificate. | |||||
| CVE-2025-61778 | 2026-06-17 | N/A | 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-61729 | 1 Golang | 1 Go | 2026-06-17 | N/A | 7.5 HIGH |
| Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. | |||||
| CVE-2025-61727 | 1 Golang | 1 Go | 2026-06-17 | N/A | 6.5 MEDIUM |
| An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com. | |||||
| CVE-2025-60022 | 2026-06-17 | N/A | 4.8 MEDIUM | ||
| 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-5279 | 2026-06-17 | N/A | N/A | ||
| 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-5025 | 1 Haxx | 1 Curl | 2026-06-17 | N/A | 4.8 MEDIUM |
| libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing. | |||||
| CVE-2025-59353 | 1 Linuxfoundation | 1 Dragonfly | 2026-06-17 | N/A | 7.5 HIGH |
| Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, a peer can obtain a valid TLS certificate for arbitrary IP addresses, effectively rendering the mTLS authentication useless. The issue is that the Manager’s Certificate gRPC service does not validate if the requested IP addresses “belong to” the peer requesting the certificate—that is, if the peer connects from the same IP address as the one provided in the certificate request. This vulnerability is fixed in 2.1.0. | |||||
| CVE-2025-59347 | 1 Linuxfoundation | 1 Dragonfly | 2026-06-17 | N/A | 6.5 MEDIUM |
| Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, The Manager disables TLS certificate verification in HTTP clients. The clients are not configurable, so users have no way to re-enable the verification. A Manager processes dozens of preheat jobs. An adversary performs a network-level Man-in-the-Middle attack, providing invalid data to the Manager. The Manager preheats with the wrong data, which later causes a denial of service and file integrity problems. This vulnerability is fixed in 2.1.0. | |||||
| CVE-2025-58781 | 2026-06-17 | N/A | 4.8 MEDIUM | ||
| WTW-EAGLE App does not properly validate server certificates, which may allow a man-in-the-middle attacker to monitor encrypted traffic. | |||||
| CVE-2025-58188 | 1 Golang | 1 Go | 2026-06-17 | N/A | 7.5 HIGH |
| Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains. | |||||
| CVE-2025-58127 | 1 Tomtretbar | 1 Dell Powerscale | 2026-06-17 | N/A | 4.8 MEDIUM |
| Improper Certificate Validation in Checkmk Exchange plugin Dell Powerscale allows attackers in MitM position to intercept traffic. | |||||
| CVE-2025-58126 | 1 Tomtretbar | 1 Vmware Vsan | 2026-06-17 | N/A | 4.8 MEDIUM |
| Improper Certificate Validation in Checkmk Exchange plugin VMware vSAN allows attackers in MitM position to intercept traffic. | |||||