CWE-295
Improper Certificate Validation
BaseDraft
Description
The product does not validate, or incorrectly validates, a certificate.
Hierarchy (View 1000)
Related attack patterns (CAPEC)
CAPEC-459 · CAPEC-475
CVEs mapped to this weakness (169)
page 1 of 9| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-4370 | Cri | 0.65 | 10.0 | 0.00 | Apr 1, 2026 | A vulnerability was identified in Juju from version 3.2.0 until 3.6.19 and from version 4.0 until 4.0.4, where the internal Dqlite database cluster fails to perform proper TLS client and server authentication. Specifically, the Juju controller's database endpoint does not validate client certificates when a new node attempts to join the cluster. An unauthenticated attacker with network reachability to the Juju controller's Dqlite port can exploit this flaw to join the database cluster. Once joined, the attacker gains full read and write access to the underlying database, allowing for total data compromise. | |
| CVE-2025-68121 | Cri | 0.65 | 10.0 | 0.00 | Feb 5, 2026 | 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-20184 | Cri | 0.64 | 9.8 | 0.00 | Apr 15, 2026 | A vulnerability in the integration of single sign-on (SSO) with Control Hub in Cisco Webex Services could have allowed an unauthenticated, remote attacker to impersonate any user within the service. This vulnerability existed because of improper certificate validation. Prior to this vulnerability being addressed, an attacker could have exploited this vulnerability by connecting to a service endpoint and supplying a crafted token. A successful exploit could have allowed the attacker to gain unauthorized access to legitimate Cisco Webex services. | |
| CVE-2025-6433 | Cri | 0.64 | 9.8 | 0.00 | Jun 24, 2025 | 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-2019-20461 | Cri | 0.64 | 9.8 | 0.00 | Nov 7, 2024 | An issue was discovered on Alecto IVM-100 2019-11-12 devices. The device uses a custom UDP protocol to start and control video and audio services. The protocol has been partially reverse engineered. Based upon the reverse engineering, no password or username is ever transferred over this protocol. Thus, one can set up the camera connection feed with only the encoded UID. It is possible to set up sessions with the camera over the Internet by using the encoded UID and the custom UDP protocol, because authentication happens at the client side. | |
| CVE-2010-1378 | Cri | 0.64 | 9.8 | 0.00 | Nov 15, 2010 | OpenSSL in Apple Mac OS X 10.6.x before 10.6.5 does not properly perform arithmetic, which allows remote attackers to bypass X.509 certificate authentication via an arbitrary certificate issued by a legitimate Certification Authority. | |
| CVE-2025-15573 | Cri | 0.61 | 9.4 | 0.00 | Feb 12, 2026 | The affected devices do not validate the server certificate when connecting to the SolaX Cloud MQTTS server hosted in the Alibaba Cloud (mqtt001.solaxcloud.com, TCP 8883). This allows attackers in a man-in-the-middle position to act as the legitimate MQTT server and issue arbitrary commands to devices. | |
| CVE-2025-3463 | Cri | 0.61 | — | 0.00 | May 9, 2025 | "This issue is limited to motherboards and does not affect laptops, desktop computers, or other endpoints." An insufficient validation vulnerability in ASUS DriverHub may allow untrusted sources to affect system behavior via crafted HTTP requests. Refer to the 'Security Update for ASUS DriverHub' section on the ASUS Security Advisory for more information. | |
| CVE-2026-22696 | Cri | 0.60 | — | 0.00 | Jan 26, 2026 | dcap-qvl implements the quote verification logic for DCAP (Data Center Attestation Primitives). A vulnerability present in versions prior to 0.3.9 involves a critical gap in the cryptographic verification process within the dcap-qvl. The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report. An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes. All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected. The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report. Users of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`. There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified. | |
| CVE-2025-61778 | Cri | 0.60 | — | 0.00 | Oct 6, 2025 | 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-2024-13990 | Cri | 0.60 | — | 0.00 | Sep 19, 2025 | MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then. | |
| CVE-2025-7395 | Cri | 0.60 | — | 0.00 | Jul 18, 2025 | A certificate verification error in wolfSSL when building with the WOLFSSL_SYS_CA_CERTS and WOLFSSL_APPLE_NATIVE_CERT_VALIDATION options results in the wolfSSL client failing to properly verify the server certificate's domain name, allowing any certificate issued by a trusted CA to be accepted regardless of the hostname. | |
| CVE-2026-5194 | Cri | 0.59 | 9.1 | 0.00 | Apr 9, 2026 | Missing hash/digest size and OID checks allow digests smaller than allowed when verifying ECDSA certificates, or smaller than is appropriate for the relevant key type, to be accepted by signature verification functions. This could lead to reduced security of ECDSA certificate-based authentication if the public CA key used is also known. This affects ECDSA/ECC verification when EdDSA or ML-DSA is also enabled. | |
| CVE-2025-70043 | Cri | 0.59 | 9.1 | 0.00 | Feb 23, 2026 | 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-7390 | Cri | 0.59 | 9.1 | 0.00 | Aug 21, 2025 | A malicious client can bypass the client certificate trust check of an opc.https server when the server endpoint is configured to allow only secure communication. | |
| CVE-2025-23114 | Cri | 0.59 | 9.0 | 0.00 | Feb 5, 2025 | A vulnerability in Veeam Updater component allows Man-in-the-Middle attackers to execute arbitrary code on the affected server. This issue occurs due to a failure to properly validate TLS certificate. | |
| CVE-2026-30836 | Cri | 0.58 | 10.0 | 0.00 | Mar 19, 2026 | Step CA is an online certificate authority for secure, automated certificate management for DevOps. Versions 0.30.0-rc6 and below do not safeguard against unauthenticated certificate issuance through the SCEP UpdateReq. This issue has been fixed in version 0.30.0. | |
| CVE-2024-41724 | Hig | 0.57 | 8.7 | 0.00 | Mar 10, 2025 | Improper Certificate Validation (CWE-295) in the Gallagher Command Centre SALTO integration allowed an attacker to spoof the SALTO server. This issue affects all versions of Gallagher Command Centre prior to 9.20.1043. | |
| CVE-2025-1014 | Hig | 0.57 | 8.8 | 0.00 | Feb 4, 2025 | Certificate length was not properly checked when added to a certificate store. In practice only trusted data was processed. This vulnerability was fixed in Firefox 135, Firefox ESR 128.7, Thunderbird 128.7, and Thunderbird 135. | |
| CVE-2022-32509 | Hig | 0.57 | 8.8 | 0.00 | May 14, 2024 | An issue was discovered on certain Nuki Home Solutions devices. Lack of certificate validation on HTTP communications allows attackers to intercept and tamper data. This affects Nuki Smart Lock 3.0 before 3.3.5, Nuki Bridge v1 before 1.22.0 and Nuki Bridge v2 before 2.13.2. |