Total
1402 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-71063 | 1 Mrvladus | 1 Errands | 2026-06-17 | N/A | 8.2 HIGH |
| Errands before 46.2.10 does not verify TLS certificates for CalDAV servers. | |||||
| CVE-2025-70058 | 1 Ymfe | 1 Yapi | 2026-06-17 | N/A | 7.4 HIGH |
| An issue pertaining to CWE-295: Improper Certificate Validation was discovered in YMFE yapi v1.12.0. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in the HTTPS agent configuration for Axios requests | |||||
| CVE-2025-70045 | 1 Jxcore | 1 Jxm | 2026-06-17 | N/A | 7.4 HIGH |
| An issue pertaining to CWE-295: Improper Certificate Validation was discovered in jxcore jxm master. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in HTTPS request options when 'jx_obj.IsSecure' is true | |||||
| CVE-2025-70044 | 1 Fofolee | 1 Utools-quickcommand | 2026-06-17 | N/A | 6.5 MEDIUM |
| An issue pertaining to CWE-295: Improper Certificate Validation was discovered in fofolee uTools-quickcommand 5.0.3. | |||||
| CVE-2025-70043 | 2026-06-17 | N/A | 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-70029 | 1 Sunbird | 1 Sunbirded-portal | 2026-06-17 | N/A | 7.5 HIGH |
| An issue in Sunbird-Ed SunbirdEd-portal v1.13.4 allows attackers to obtain sensitive information. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in HTTP request options | |||||
| CVE-2025-6433 | 1 Mozilla | 1 Firefox | 2026-06-17 | N/A | 9.8 CRITICAL |
| If a user visited a webpage with an invalid TLS certificate, and granted an exception, the webpage was able to provide a WebAuthn challenge that the user would be prompted to complete. This is in violation of the WebAuthN spec which requires "a secure transport established without errors". This vulnerability was fixed in Firefox 140 and Thunderbird 140. | |||||
| CVE-2025-6037 | 1 Hashicorp | 1 Vault | 2026-06-17 | N/A | 6.8 MEDIUM |
| Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as [+trusted certificate+|https://developer.hashicorp.com/vault/api-docs/auth/cert#certificate]. In this configuration, an attacker may be able to craft a malicious certificate that could be used to impersonate another user. Fixed in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23. | |||||
| CVE-2025-6026 | 2026-06-17 | N/A | 3.1 LOW | ||
| 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. | |||||
| CVE-2025-69412 | 2026-06-17 | N/A | 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-68482 | 1 Fortinet | 2 Fortianalyzer, Fortimanager | 2026-06-17 | N/A | 6.9 MEDIUM |
| A improper certificate validation vulnerability in Fortinet FortiAnalyzer 7.6.0 through 7.6.4, FortiAnalyzer 7.4.0 through 7.4.8, FortiAnalyzer 7.2 all versions, FortiAnalyzer 7.0 all versions, FortiAnalyzer 6.4 all versions, FortiManager 7.6.0 through 7.6.4, FortiManager 7.4.0 through 7.4.8, FortiManager 7.2 all versions, FortiManager 7.0 all versions, FortiManager 6.4 all versions may allow a remote unauthenticated attacker to view confidential information via a man in the middle [MiTM] attack. | |||||
| CVE-2025-68161 | 1 Apache | 1 Log4j | 2026-06-17 | N/A | 4.8 MEDIUM |
| The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. | |||||
| CVE-2025-68121 | 1 Golang | 1 Go | 2026-06-17 | N/A | 10.0 CRITICAL |
| During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. | |||||
| CVE-2025-67752 | 1 Open-emr | 1 Openemr | 2026-06-17 | N/A | 8.1 HIGH |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 7.0.4, OpenEMR's HTTP client wrapper (`oeHttp`/`oeHttpRequest`) disables SSL/TLS certificate verification by default (`verify: false`), making all external HTTPS connections vulnerable to man-in-the-middle (MITM) attacks. This affects communication with government healthcare APIs and user-configurable external services, potentially exposing Protected Health Information (PHI). Version 7.0.4 fixes the issue. | |||||
| CVE-2025-67601 | 1 Suse | 1 Rancher | 2026-06-17 | N/A | 8.3 HIGH |
| A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the -skip-verify flag to the Rancher CLI login command without also passing the –cacert flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. | |||||
| CVE-2025-67229 | 1 Todesktop | 1 Builder | 2026-06-17 | N/A | 9.8 CRITICAL |
| An improper certificate validation vulnerability exists in ToDesktop Builder v0.32.1 This vulnerability allows an unauthenticated, on-path attacker to spoof backend responses by exploiting insufficient certificate validation. | |||||
| CVE-2025-66614 | 1 Apache | 1 Tomcat | 2026-06-17 | N/A | 9.1 CRITICAL |
| Improper Input Validation vulnerability. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected. Tomcat did not validate that the host name provided via the SNI extension was the same as the host name provided in the HTTP host header field. If Tomcat was configured with more than one virtual host and the TLS configuration for one of those hosts did not require client certificate authentication but another one did, it was possible for a client to bypass the client certificate authentication by sending different host names in the SNI extension and the HTTP host header field. The vulnerability only applies if client certificate authentication is only enforced at the Connector. It does not apply if client certificate authentication is enforced at the web application. Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue. | |||||
| CVE-2025-66491 | 1 Traefik | 1 Traefik | 2026-06-17 | N/A | 5.9 MEDIUM |
| Traefik is an HTTP reverse proxy and load balancer. Versions 3.5.0 through 3.6.2 have inverted TLS verification logic in the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation. Setting the annotation to "on" (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected. This issue is fixed in version 3.6.3. | |||||
| CVE-2025-66001 | 2026-06-17 | N/A | 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-65830 | 1 Meatmeet | 1 Meatmeet | 2026-06-17 | N/A | 9.1 CRITICAL |
| Due to a lack of certificate validation, all traffic from the mobile application can be intercepted. As a result, an adversary located "upstream" can decrypt the TLS traffic, inspect its contents, and modify the requests in transit. This may result in a total compromise of the user's account if the attacker intercepts a request with active authentication tokens or cracks the MD5 hash sent on login. | |||||