Multiple +Message Apps (Softbank +Message App for Android prior to version 10.1.7, Softbank +Message App for iOS prior to version 1.1.23, NTT DOCOMO +Message App for Android prior to version 42.40.2800, NTT DOCOMO +Message App for iOS prior to version 1.1.23, KDDI +Message App for Android prior to version 1.0.6, and KDDI +Message App for iOS prior to version 1.1.23) do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on macOS systems. Additionally, SNI validation is also not enabled when the CA has been “overridden”. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker. The 'aws_tls_ctx_options_override_default_trust_store_*' function within the aws-c-io submodule has been updated to address this behavior. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.7.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.14.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.6.0 on macOS. Amazon Web Services AWS-C-IO 0.10.7 on macOS.

An issue was discovered in certain Apple products. macOS before 10.12.5 is affected. The issue involves the "802.1X" component. It allows remote attackers to discover the network credentials of arbitrary users by operating a crafted network that requires 802.1X authentication, because EAP-TLS certificate validation mishandles certificate changes.

An issue was discovered in certain Apple products. iOS before 11 is affected. macOS before 10.13 is affected. tvOS before 11 is affected. watchOS before 4 is affected. The issue involves the "Security" component. It allows remote attackers to bypass intended certificate-trust restrictions via a revoked X.509 certificate.

An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. The issue involves the "Security" component. It allows attackers to bypass intended access restrictions via an untrusted certificate.

The RBB SPEED TEST App for Android version 2.0.3 and earlier, RBB SPEED TEST App for iOS version 2.1.0 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems.

This issue was addressed through improved state management. This issue is fixed in Safari 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4. Private Browsing tabs may be accessed without authentication.

The Planet Fitness Workouts iOS and Android mobile apps fail to properly validate TLS certificates, allowing an attacker with appropriate network access to obtain session tokens and sensitive information. Planet Fitness first addressed this vulnerability in version 9.8.12 (released on 2024-07-25) and more recently in version 9.9.13 (released on 2025-02-11).

A certificate validation issue was addressed. This issue is fixed in iOS 14.5 and iPadOS 14.5. An attacker in a privileged network position may be able to alter network traffic.

Dell NetWorker, contains an Improper Validation of Certificate with Host Mismatch vulnerability in Rabbitmq port which could disallow replacing CA signed certificates.

The certificate used to identify the Silver Peak Cloud Portal to EdgeConnect devices is not validated. This makes it possible for someone to establish a TLS connection from EdgeConnect to an untrusted portal.

The certificate used to identify Orchestrator to EdgeConnect devices is not validated, which makes it possible for someone to establish a TLS connection from EdgeConnect to an untrusted Orchestrator.

All versions of GitLab CE/EE starting from 12.8 before 13.10.5, all versions starting from 13.11 before 13.11.5, and all versions starting from 13.12 before 13.12.2 were affected by an issue in the handling of x509 certificates that could be used to spoof author of signed commits.

Entrust Entelligence Security Provider (ESP) before 10.0.60 on Windows mishandles errors during SSL Certificate Validation, leading to situations where (for example) a user continues to interact with a web site that has an invalid certificate chain.

In Yealink RPS before 2025-05-26, the certificate upload function does not properly validate certificate content, potentially allowing invalid certificates to be uploaded.

An issue exists in PrimeKey EJBCA before 7.4.3 when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA's domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over an EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. NOTE: an attacker must already have a trusted client certificate and authorization to enroll against the targeted CA.

A flaw was found in JBCS httpd in version 2.4.37 SP3, where it uses a back-end worker SSL certificate with the keystore file's ID is 'unknown'. The validation of the certificate whether CN and hostname are matching stopped working and allow connecting to the back-end work. The highest threat from this vulnerability is to data integrity.

IBM i 7.2, 7.3, 7.4, 7.5, and 7.6 is vulnerable to authentication and authorization attacks due to incorrect validation processing in IBM i Netserver. A malicious actor could use the weaknesses, in conjunction with brute force authentication attacks or to bypass authority restrictions, to access the server.

Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade.

An authentication bypass flaw was found in the way krb5's certauth interface before 1.16.1 handled the validation of client certificates. A remote attacker able to communicate with the KDC could potentially use this flaw to impersonate arbitrary principals under rare and erroneous circumstances.

curl before 7.53.0 has an incorrect TLS Certificate Status Request extension feature that asks for a fresh proof of the server's certificate's validity in the code that checks for a test success or failure. It ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. This flaw also exists in the command line tool (--cert-status).

An issue was discovered in Mattermost Server before 3.7.3 and 3.6.5. A System Administrator can place a SAML certificate at an arbitrary pathname.

A flaw was found in keycloak affecting versions 11.0.3 and 12.0.0. An expired certificate would be accepted by the direct-grant authenticator because of missing time stamp validations. The highest threat from this vulnerability is to data confidentiality and integrity.