Total
1277 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-2748 | 1 Seppmail | 1 Seppmail | 2026-03-05 | N/A | 5.3 MEDIUM |
| SEPPmail Secure Email Gateway before version 15.0.1 improperly validates S/MIME certificates issued for email addresses containing whitespaces, allowing signature spoofing. | |||||
| CVE-2025-67601 | 1 Suse | 1 Rancher | 2026-03-03 | 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-2026-27133 | 1 Linuxfoundation | 1 Strimzi | 2026-02-27 | N/A | 5.9 MEDIUM |
| Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. From 0.47.0 to before 0.50.1, when a chain consisting of multiple CA (Certificate Authority) certificates is used in the trusted certificates configuration of a Kafka Connect operand or of the target cluster in the Kafka MirrorMaker 2 operand, all of the certificates that are part of the CA chain will be trusted individually when connecting to the Apache Kafka cluster. Due to this error, the affected operand (Kafka Connect or Kafka MirrorMaker 2) might accept connections to Kafka brokers using server certificates signed by one of the other CAs in the CA chain and not just by the last CA in the chain. This issue is fixed in Strimzi 0.50.1. | |||||
| CVE-2025-27377 | 1 Altium | 1 Designer | 2026-02-26 | N/A | 5.3 MEDIUM |
| Altium Designer version 24.9.0 does not validate self-signed server certificates for cloud connections. An attacker capable of performing a man-in-the-middle (MITM) attack could exploit this issue to intercept or manipulate network traffic, potentially exposing authentication credentials or sensitive design data. | |||||
| CVE-2025-70044 | 1 Fofolee | 1 Utools-quickcommand | 2026-02-26 | 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-70045 | 1 Jxcore | 1 Jxm | 2026-02-26 | 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-70058 | 1 Ymfe | 1 Yapi | 2026-02-26 | 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-2026-3100 | 1 Asustor | 1 Data Master | 2026-02-26 | N/A | 6.5 MEDIUM |
| The FTP Backup on the ADM will not properly strictly enforce TLS certificate verification while connecting to an FTP server using FTPES/FTPS. An improper validated TLS/SSL certificates allows a remote attacker can intercept network traffic to perform a Man-in-the-Middle (MitM) attack, which may intercept, modify, or obtain sensitive information such as authentication credentials and backup data. Affected products and versions include: from ADM 4.1.0 through ADM 4.3.3.ROF1 as well as from ADM 5.0.0 through ADM 5.1.2.RE51. | |||||
| CVE-2026-27134 | 1 Linuxfoundation | 1 Strimzi Kafka Operator | 2026-02-25 | N/A | 8.1 HIGH |
| Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used. | |||||
| CVE-2025-67752 | 1 Open-emr | 1 Openemr | 2026-02-25 | 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-2022-32156 | 1 Splunk | 2 Splunk, Universal Forwarder | 2026-02-25 | 6.8 MEDIUM | 8.1 HIGH |
| In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties. The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High. | |||||
| CVE-2026-21228 | 1 Microsoft | 1 Azure Local | 2026-02-25 | N/A | 8.1 HIGH |
| Improper certificate validation in Azure Local allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2025-70043 | 2026-02-23 | 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-2013-6662 | 1 Google | 1 Chrome | 2026-02-23 | 4.3 MEDIUM | 6.5 MEDIUM |
| Google Chrome caches TLS sessions before certificate validation occurs. | |||||
| CVE-2026-25644 | 1 Datahub | 1 Datahub | 2026-02-20 | N/A | 7.5 HIGH |
| DataHub is an open-source metadata platform. Prior to version 1.3.1.8, the LDAP ingestion source is vulnerable to MITM attack through TLS downgrade. This issue has been patched in version 1.3.1.8. | |||||
| CVE-2026-25961 | 1 Sumatrapdfreader | 1 Sumatrapdf | 2026-02-20 | N/A | 7.5 HIGH |
| SumatraPDF is a multi-format reader for Windows. In 3.5.0 through 3.5.2, SumatraPDF's update mechanism disables TLS hostname verification (INTERNET_FLAG_IGNORE_CERT_CN_INVALID) and executes installers without signature checks. A network attacker with any valid TLS certificate (e.g., Let's Encrypt) can intercept the update check request, inject a malicious installer URL, and achieve arbitrary code execution. | |||||
| CVE-2026-24122 | 1 Sigstore | 1 Cosign | 2026-02-20 | N/A | 3.7 LOW |
| Cosign provides code signing and transparency for containers and binaries. In versions 3.0.4 and below, an issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired. When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. There is no impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. This issue has been fixed in version 3.0.5. | |||||
| CVE-2025-68121 | 1 Golang | 1 Go | 2026-02-20 | 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-2026-24935 | 1 Asustor | 1 Data Master | 2026-02-19 | N/A | 5.6 MEDIUM |
| A third-party NAT traversal module fails to validate SSL/TLS certificates when connecting to the signaling server. While subsequent access to device services requires additional authentication, a Man-in-the-Middle (MitM) attacker can intercept or redirect the NAT tunnel establishment. This could allow an attacker to disrupt service availability or facilitate further targeted attacks by acting as a proxy between the user and the device services. Affected products and versions include: from ADM 4.1.0 through ADM 4.3.3.ROF1 as well as from ADM 5.0.0 through ADM 5.1.1.RCI1. | |||||
| CVE-2026-24934 | 1 Asustor | 1 Data Master | 2026-02-19 | N/A | 3.7 LOW |
| The DDNS function uses an insecure HTTP connection or fails to validate the SSL/TLS certificate when querying an external server for the device's WAN IP address. An unauthenticated remote attacker can perform a Man-in-the-Middle (MitM) attack to spoof the response, leading the device to update its DDNS record with an incorrect IP address. Affected products and versions include: from ADM 4.1.0 through ADM 4.3.3.ROF1 as well as from ADM 5.0.0 through ADM 5.1.1.RCI1. | |||||