| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| Google Chrome caches TLS sessions before certificate validation occurs. |
| Improper certificate validation in Azure Local allows an unauthorized attacker to execute code over a network. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| The API communication component fails to validate the SSL/TLS certificate when sending HTTPS requests to the server. An improper certificates validation vulnerability allows an unauthenticated remote attacker can perform a Man-in-the-Middle (MitM) attack to intercept the cleartext communication, potentially leading to the exposure of sensitive user information, including account emails, MD5 hashed passwords, and device serial numbers.
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. |
| The DDNS update function in ADM fails to properly validate the hostname of the DDNS server's TLS/SSL certificate. Although the connection uses HTTPS, an improper validated TLS/SSL certificates allows a remote attacker can intercept the communication to perform a Man-in-the-Middle (MitM) attack, which may obtain the sensitive information of DDNS updating process, including the user's account email, MD5 hashed password, and device serial number.This issue affects ADM: from 4.1.0 through 4.3.3.ROF1, from 5.0.0 through 5.1.1.RCI1. |
| An issue in the TLS certification mechanism of Guardian Gryphon v01.06.0006.22 allows attackers to execute commands as root. |
| Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.
When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.
This issue affects Apache Tomcat Native: from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.
The following versions were EOL at the time the CVE was created but are
known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.
Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.
Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue. |
| In Modem, there is a possible permission bypass due to improper certificate validation. This could lead to remote information disclosure, if a UE has connected to a rogue base station controlled by the attacker, with User execution privileges needed. User interaction is needed for exploitation. Patch ID: MOLY01334347; Issue ID: MSV-2772. |
| A vulnerability in the certificate validation logic may allow applications to accept untrusted or improperly validated server identities during TLS communication. An attacker in a privileged network position may be able to intercept or modify traffic if they can position themselves within the communication channel. Successful exploitation may compromise confidentiality, integrity, and availability of application data. |
| Improper Certificate Validation vulnerability in Thales SafeNet Agent for Windows Logon on Windows allows Signature Spoofing by Improper Validation.This issue affects SafeNet Agent for Windows Logon: 4.0.0, 4.1.1, 4.1.2. |
| Alist is a file list program that supports multiple storages, powered by Gin and Solidjs. Prior to version 3.57.0, the application disables TLS certificate verification by default for all outgoing storage driver communications, making the system vulnerable to Man-in-the-Middle (MitM) attacks. This enables the complete decryption, theft, and manipulation of all data transmitted during storage operations, severely compromising the confidentiality and integrity of user data. This issue has been patched in version 3.57.0. |
| Improper certificate validation in Windows SMB allows an authorized attacker to perform spoofing over a network. |
| An Improper Certificate Validation vulnerability in TP-Link Tapo H100 v1 and Tapo P100 v1 allows an on-path attacker on the same network segment to intercept and modify encrypted device-cloud communications. This may compromise the confidentiality and integrity of device-to-cloud communication, enabling manipulation of device data or operations. |
