CVE Database

CVE-2026-92543 High · 7.6 CWE-295 Oct 7, 2026

Docker Engine insecure-registry fallback via malicious DNS responses

Docker Engine classifies a registry hostname as insecure using an any-match DNS check. loadInsecureRegistries() injects 127.0.0.0/8 and ::1/128 as insecure CIDRs by default. isCIDRMatch resolves all of the hostname's addresses and returns true if a single address is in the insecure CIDR list. Because the transport re-dials the hostname rather than the CIDR-matching address, a DNS answer set of one loopback IP plus a non-loopback attacker IP disables certificate verification and enables HTTP fallback for the registry connection.

CVE-2026-63697 High · 7.2 CWE-295 Oct 6, 2026

Improper Certificate Validation in Dell System Update

Dell System Update, versions prior to 2.3.0.0, contains an Improper Certificate Validation vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Remote execution.

CVE-2026-67270 High · 7.4 CWE-295 Oct 6, 2026

Dell Container Storage Modules (CSM) versions prior to 1.18.0, contains an Improper Certificate...

Dell Container Storage Modules (CSM) versions prior to 1.18.0, contains an Improper Certificate Validation vulnerability in the proxy-server component. An unauthenticated adjacent network attacker could potentially exploit this vulnerability, leading to information exposure of storage backend administrator credentials.

CVE-2026-105794 Critical · 9.1 CWE-295 Oct 6, 2026

MsQuic: Improper Certificate Validation in Microsoft.Native.Quic.MsQuic.OpenSSL

MsQuic is a cross-platform C implementation of the IETF QUIC protocol exposed to C, C++, C#, and Rust. Prior to 2.4.20, 2.5.11, and 2.6.1, MsQuic clients using the OpenSSL or QuicTLS TLS backend do not properly verify that a server certificate matches the intended target server hostname. An on-path attacker can therefore present a certificate that does not match the intended target hostname and spoof the server in a man-in-the-middle attack. The Schannel backend is not affected. This issue is fixed in versions 2.4.20, 2.5.11, and 2.6.1.

CVE-2026-105223 High · 7.4 CWE-295 Oct 4, 2026

maclof kubernetes-client 0.17.0 before 0.32.0 Disabled TLS Certificate Verification

maclof kubernetes-client 0.17.0 before 0.32.0 disables TLS certificate verification in parseKubeconfig() and parseKubeconfigFile() when a kubeconfig lacks certificate-authority-data, ignoring insecure-skip-tls-verify. On-path attackers can impersonate the Kubernetes API server to capture Bearer tokens or Basic credentials and tamper with WebSocket or REST API traffic.

CVE-2026-105222 High · 7.4 CWE-295 Oct 4, 2026

alexpechkarev/google-maps through 12.16 Disabled TLS Certificate Verification via ssl_verify_peer

The alexpechkarev/google-maps Laravel package through 12.16 disables TLS certificate verification by default because the bundled config sets ssl_verify_peer to FALSE, which is passed to CURLOPT_SSL_VERIFYPEER. On-path attackers can present any certificate to intercept Google Maps web-service requests, steal the API key from the query string, and tamper with responses.

CVE-2026-105221 High · 7.4 Public exploit CWE-295 Oct 4, 2026

Gist RubyGem before 6.1.0 Disabled TLS Certificate Verification

The gist RubyGem before 6.1.0 contains an improper certificate validation vulnerability that allows on-path attackers to intercept HTTPS traffic because http_connection in lib/gist.rb sets VERIFY_NONE. Attackers can present any certificate to read or modify GitHub API traffic, stealing OAuth tokens and login credentials to read and modify the victim's gists.

CVE-2026-105218 High · 7.4 CWE-295 Oct 4, 2026

gopay before 1.5.119 Disabled TLS Certificate Verification in xhttp Client

gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go, allowing man-in-the-middle attackers to impersonate payment provider APIs. Attackers can present any certificate to read merchant credentials, signatures and transaction data, and modify payment, refund and order query responses.

CVE-2026-105217 Low · 3.1 CWE-295 Oct 4, 2026

Cockpit CMS 2.12.0 before 2.14.1 Disabled TLS Verification via cron.php

Cockpit CMS 2.12.0 before 2.14.1 disables TLS certificate verification in the cron.php web worker restart request, allowing network attackers to capture the worker token. Man-in-the-middle attackers on the outbound path to site_url can present any certificate to steal the worker/web/token value and start the web worker.

CVE-2026-105216 High · 7.4 CWE-295 Oct 4, 2026

go-micro before 6.0.0 Disabled TLS Certificate Verification via tls.Config Helper

go-micro before 6.0.0 contains an improper certificate validation vulnerability that allows network attackers to impersonate services because the shared TLS helper sets InsecureSkipVerify to true by default. Man-in-the-middle attackers can present any certificate to intercept or modify gRPC transport, HTTP and RabbitMQ broker, and Consul or etcd registry traffic, including authentication tokens and credentials.

CVE-2026-71889 High · 8.7 CWE-295 Oct 3, 2026

PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate

In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).

CVE-2026-85088 Medium · 6.9 CWE-295 Oct 2, 2026

Apache Thrift, Apache Thrift: The C++ and D clients fall back to the certificate Common Name when subjectAltName entries are present but do not match

Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the accessManager property does so in D — which compares the peer certificate against the host name that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a "skip" result rather than a rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection to the second name. Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client's trust store and whose Common Name matches the connected host name. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0.

CVE-2026-85087 Medium · 6.9 CWE-295 Oct 2, 2026

Apache Thrift: Python ≥3.12 host-name check silently becomes a no-op

Improper certificate validation, Return of wrong status code vulnerability in Apache Thrift python bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue.

CVE-2026-85086 Medium · 6.9 CWE-295 Oct 2, 2026

Apache Thrift: Perl TLS client disables certificate verification by default

Improper certificate validation, Initialization of a resource with an insecure default vulnerability in Apache Thrift perl bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue.

CVE-2026-80443 High · 7.4 CWE-295 Oct 2, 2026

Insecure TLS Certificate Validation in API Tool Runner in HAVELSAN's Sef - AI Chatbot Platform

Improper certificate validation vulnerability in HAVELSAN Inc. Sef - AI Chatbot Platform allows Adversary in the Middle (AiTM). This issue affects Sef - AI Chatbot Platform: before 2.1. NOTE: The vendor was contacted and it was learned that the product is not supported.

CVE-2026-63577 High · 8.2 CWE-295 Oct 2, 2026

Name Constraints bypass: directoryName constraint matched at any position in the DN instead of as a prefix

Improper certificate validation in the directoryName name-constraint check (PkixNameConstraintValidator.WithinDNSubtree) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who controls, or can have certificates issued by, a name-constrained intermediate CA to get certificates accepted by PKIX path validation whose subject distinguished name, or a directoryName subjectAltName, lies outside the CA's permitted subtrees, via a name that places other RDNs ahead of a copy of the permitted RDN sequence, because the check looks for the constraint's first RDN anywhere in the name and compares the remaining RDNs from that position, instead of requiring the constraint to be an initial prefix of the name as RFC 5280 sections 4.2.1.10 and 7.1 require.

CVE-2026-63576 High · 8.2 CWE-295 Oct 2, 2026

URI name constraints checked against a mis-parsed host

Improper certificate validation in PkixNameConstraintValidator (ExtractHostFromURL) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a name-constrained subordinate CA, or anyone able to obtain certificates with chosen subjectAltName URIs from such a CA, to bypass permitted or excluded uniformResourceIdentifier name constraints during certification path validation via a URI whose path, query, fragment or userinfo contains characters such as '@' or ':', because the host was extracted by string slicing without first isolating the RFC 3986 authority component, so the host compared against the constraints could differ from the URI's actual host.

CVE-2026-103602 High · 8.2 CWE-295 Oct 2, 2026

Name constraints bypass via trailing dot in rfc822Name, dNSName and URI hosts

Improper certificate validation in PkixNameConstraintValidator in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who controls, or can obtain certificates from, a name-constrained intermediate CA to have certificates accepted during PKIX certification path validation for email addresses, DNS names or URI hosts that lie within excluded subtrees applying to that CA, via an rfc822Name, dNSName or uniformResourceIdentifier name whose host ends with a dot, because names and constraints were compared without first removing the RFC 1034 root-label trailing dot, so a fully qualified host name did not match an excluded subtree for the same host written without the dot.

CVE-2026-102671 Medium · 5.3 CWE-295 Oct 1, 2026

Joyland AI WebView accepts invalid SSL certificates

The Joyland AI app accepts invalid SSL certificates in the invisible advertisement WebView by default.

CVE-2026-102668 Medium · 5.3 CWE-295 Oct 1, 2026

Joyland AI accepts TLS certificates without validation

The Joyland AI app accepts any TLS certificates from any server without validation.

CVE-2026-15911 High · 7.4 CWE-295 Oct 1, 2026

Confluent Kafka Python Improper TLS Certificate Validation

Confluent Kafka Python client's HashiCorp Vault KMS integration could allow a remote attacker to obtain sensitive information due to improper TLS certificate validation.

CVE-2026-103921 High · 7.4 CWE-295 Oct 1, 2026

GraphQL Tools: TLS Certificate Validation Disabled in Legacy GraphQL WebSocket Executor

GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to 1.1.35, the executor-legacy-ws buildWSLegacyExecutor() function hardcodes TLS certificate rejection off for Node.js connections to wss:// endpoints. Applications using the executor directly, or url-loader with SubscriptionProtocol.LEGACY_WS, can therefore accept an attacker-controlled certificate when a network-positioned attacker intercepts the connection. Authentication material in connectionParams or headers can be disclosed, and subscription data can be modified. Browser WebSocket clients are unaffected because browsers enforce certificate validation. This issue is fixed in version 1.1.35.

CVE-2026-92868 Medium · 6.5 CWE-295 Sep 30, 2026

Improper Certificate Validation in Pgpool Global Development Group Pgpool-II

An improper certificate validation vulnerability exists in Pgpool-II, which may allow an unauthenticated attacker to bypass client certificate authentication.

CVE-2026-102508 Critical · 9.2 CWE-295 Sep 30, 2026

Apache PLC4X: OPC UA secure channel: integrity bypass, unverifiable server certificate, and silent downgrade

Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client. The defect manifests differently depending on the version: - In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password. - In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default. - In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint. Users checking only for one of these mechanisms may wrongly conclude they are unaffected. This issue affects Apache PLC4X: from 0.9.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the connection if the negotiated security policy is weaker than the configured one.

CVE-2026-97687 High · 8.1 CWE-295 Sep 29, 2026

urllib3: HTTPS proxy TLS configuration may be ignored or overridden

urllib3 is an HTTP client library for Python. From 1.26.0 until 2.8.0, the proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, use_forwarding_for_https=True, and CERT_NONE configuration paths fail to remain separated because target-server TLS settings are incorrectly applied to the HTTPS proxy connection. The trigger is that an application uses an HTTPS proxy and configures target-server TLS settings that must remain separate from the proxy TLS handshake, including HTTPS forwarding with target-specific identity or credentials. Applying cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and the mutation persists so later connections reusing the same context may connect to the HTTPS proxy without certificate verification. The attack mechanism is that an attacker intercepts and impersonates the HTTPS proxy after the effective proxy policy accepts the attacker's certificate. The impact is that the attacker can observe or modify forwarded traffic or receive a target TLS client certificate, while CONNECT tunneling still preserves the separate end-to-end target TLS connection. This issue is fixed in version 2.8.0.