Overview 750 matches · 52 in Waratek scope · 1 protected · 4 exploited · 3 CISA KEV · 10 public PoC · 2 EPSS ≥ 0.5
750matches
52in Waratek scope6.9%
1protected0.1%
4exploited0.5%
3CISA KEV0.4%
10public PoC1.3%
2EPSS ≥ 0.50.3%
Protected by Waratek
1
0.1%
Rule in development
0
0.0%
Mitigation candidate
1
0.1%
No exploit published
50
6.7%
Outside Waratek scope
12
1.6%
Not applicable
686
91.5%
Withdrawn CVE
0
0.0%
blocked by ARMR today
1
0.1%
partly blocked
0
0.0%
not blocked
749
99.9%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 242 / year
20031
No exploit published1
High1
not blocked1
No public exploit1
20040
20050
20060
20070
20080
20092
Not applicable2
High2
not blocked2
No public exploit2
20100
20110
20123
No exploit published1
Not applicable2
High3
not blocked3
No public exploit3
20130
20141
Not applicable1
High1
not blocked1
Proof of concept only1
20151
Not applicable1
High1
not blocked1
No public exploit1
20161
Outside Waratek scope1
High1
not blocked1
No public exploit1
201742
No exploit published1
Not applicable41
High42
not blocked42
Working exploit published1
No public exploit41
201864
No exploit published7
Outside Waratek scope4
Not applicable53
High64
not blocked64
Working exploit published1
Proof of concept only2
No public exploit61
201956
No exploit published6
Outside Waratek scope1
Not applicable49
High56
not blocked56
No public exploit56
202052
No exploit published4
Outside Waratek scope1
Not applicable47
High52
not blocked52
Exploited1
Proof of concept only1
No public exploit50
202162
No exploit published2
Outside Waratek scope2
Not applicable58
High62
not blocked62
Proof of concept only1
No public exploit61
202246
No exploit published7
Outside Waratek scope2
Not applicable37
High46
not blocked46
Exploited1
Proof of concept only4
No public exploit41
202356
No exploit published3
Not applicable53
High56
not blocked56
Exploited1
Proof of concept only3
No public exploit52
202462
No exploit published2
Not applicable60
High62
not blocked62
Working exploit published1
Proof of concept only5
No public exploit56
202559
No exploit published4
Not applicable55
High59
not blocked59
Proof of concept only6
No public exploit53
2026242
Protected by Waratek1
Mitigation candidate1
No exploit published12
Outside Waratek scope1
Not applicable227
High242
blocked by ARMR today1
not blocked241
Exploited1
Working exploit published1
Proof of concept only21
No public exploit219
200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-102612 | High | 2026-11-13 | Not applicable | No public exploit | BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.6, 1.5.2, and 1.6.1, bws_srv_start() in ports/linux/websocket-srv.c builds the libwebsockets server context with a CA certificate loaded but never sets LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, so the hub accepts TLS connections from clients presenting no certificate at all. Any network-reachable host can join the BACnet/SC mesh without credentials. This issue has been patched in versions 1.4.6, 1.5.2, 1.6.1, and 1.7.0. |
| CVE-2026-102537 | High | 2026-11-13 | Not applicable | No public exploit | BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.6, 1.5.2, and 1.6.1, bws_cli_connect() in ports/linux/websocket-cli.c loads the trusted CA cert into the libwebsockets context, then always sets LCCSCF_ALLOW_SELFSIGNED in the connection flags. So lws accepts any self-signed hub certificate, whether or not it chains to the loaded CA. A BACnet/SC node finishes the TLS handshake to a rogue hub that presents a self-signed cert. It then hands the attacker its identity (VMAC, UUID) and all later BACnet traffic. This issue has been patched in versions 1.4.6, 1.5.2, 1.6.1, and 1.7.0. |
| CVE-2026-91890 | High | 2026-11-11 | Not applicable | No public exploit | Dell Ansible Storage for Unity , versions prior to 1.2.13 contains an Improper Certificate Validation vulnerability in the UnityRESTConnector component. An unauthenticated attacker with remote access could potentially exploit this vulnerability,leading to information exposure and unauthorized access. |
| CVE-2026-91880 | High | 2026-11-11 | Not applicable | No public exploit | Dell Terraform Provider for PowerFlex, versions 1.5.0 through 1.8.0, contains an Improper Certificate Validation vulnerability in the SSH client component.Terraform PowerFlex provider uses ssh.InsecureIgnoreHostKey() as the default SSH host key callback. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-91875 | High | 2026-11-11 | Not applicable | No public exploit | Dell OpenManage Ansible Modules, versions 9.2.0 through 10.0.3, contains an Improper Certificate Validation vulnerability in the SessionAPI component. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-91874 | High | 2026-11-11 | Not applicable | No public exploit | Dell OpenManage Ansible Modules, versions 5.0.0 through 10.0.3, contains an Improper Certificate Validation vulnerability in the iDRACConnection component. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-91873 | High | 2026-11-11 | Not applicable | No public exploit | Dell OpenManage Ansible Modules, versions 2.1.2 through 10.0.3, contains an Improper Certificate Validation vulnerability in the iDRACRedfishAPI component. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-91871 | High | 2026-11-11 | Not applicable | No public exploit | Dell Ansible Storage for PowerStore, versions prior to 3.9.0, contains an Improper Certificate Validation vulnerability in the API client component. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-91870 | High | 2026-11-11 | Not applicable | No public exploit | Dell Ansible Storage for PowerFlex, versions prior to 3.2.0, contains an Improper Certificate Validation vulnerability in the API client component. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to information exposure and unauthorized access. |
| CVE-2026-64855 | High | 2026-11-11 | Not applicable | No public exploit | soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verify_envelope_bsp() derived its trust anchor from the message it was verifying. It read the X.509 certificate out of the caller-untrusted wsse:BinarySecurityToken, validated only that certificate's not-before / not-after dates, and then verified the signature against that same certificate. There was no CA-chain validation, no issuer/subject allowlist, and no pinning. A successful verify_envelope_bsp() therefore proved only that the envelope was signed by whoever supplied the embedded certificate — never that it was signed by a trusted party. An attacker who mints their own certificate, signs a forged envelope, and embeds that certificate in the token passes verification. Any consumer that treats a successful BSP verification as authentication can be impersonated (signature forgery / authentication bypass). verify_envelope() (which pins a caller-supplied x509_cert) was not affected — the flaw was specific to the BSP variant whose trust anchor came from the message. This issue has been patched in version 0.13.0. |
| CVE-2026-126621 | High | 2026-11-11 | Not applicable | No public exploit | Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 on Windows hands OpenSSL the names of its own TLS files - the listeners' certificates, chains, private keys and Diffie-Hellman parameters, a port's client-certificate CA file (from 6.2.19), the object store's CA file (from 6.3.4) and the ACME client's keys and certificates - as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF, and OpenSSL's file opening on Windows reads a name as UTF-8 first and opens the file at that reading when it is there, or creates it there when its folder is. When every byte of a configured name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9, which are U+00E9 in UTF-8 - the server used the file at that other name whenever one was there, which allows a local attacker who can create that file or its folder but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, to have a port that logs on by client certificate (from 6.2.25) accept certificates from a certificate authority of the attacker's own and so sign in over the network as any mailbox without its password; to have the server trust such an authority for its object store and, intercepting that connection, read and modify the messages it stores; to receive the private keys the ACME client writes, the key of a certificate issued for the server's names among them; or to keep TLS ports from starting. The configuration is not the default: by default these files have names in ASCII, client certificates are off on every port, and the object store and ACME are off. The Linux builds are not affected. |
| CVE-2026-126611 | High | 2026-11-11 | Not applicable | No public exploit | Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database, TlsMode=verify-full and no TlsCaFile, does not verify the database server's certificate's issuer or name when the connection is one that MariaDB Connector/C treats as local - Server= set to 127.0.0.1, ::1 or localhost (on Linux a Unix socket), to . on Windows (a named pipe), or to a comma-separated list of servers that holds such an element - which allows a local attacker who can stand in for the database server, for example by listening on its port while it is stopped or restarting, to receive the database sign-in, the password included, and to read and modify the traffic between hMailServer and its database. hMailServer applied verify-full by turning the client's certificate verification on without a CA file, but MariaDB Connector/C 3.4.1 and later, on a connection they treat as local and with no CA file, accept any certificate within its validity period that is self-signed or sent with its own root, for any name (Connector/C 3.4.2 to 3.4.10 also one whose issuer they cannot find), so the client accepted the certificate an impostor made, asked no proof of the password and allowed a switch to an authentication method that sends the password unhashed, while hmailserver --check-database said the certificate had been checked against the system's trust store and the application log that it had been checked. The Windows builds bundle Connector/C 3.4.9 (6.3.4 to 6.3.6) and 3.4.11 (6.3.7); on Linux the distribution's client is used, and Connector/C 3.3 and 3.4.0 and Oracle's MySQL client are not affected. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate. |
| CVE-2026-126610 | High | 2026-11-11 | Not applicable | No public exploit | Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database and TlsMode=verify-full, does not hand the database client the CA file that TlsCaFile names when the file's name contains a character outside ASCII on Linux, or above U+00FF on Windows, which allows an attacker who can intercept the connection to the database server to read and modify the traffic between hMailServer and its database, by presenting, with MariaDB Connector/C 3.4.2 to 3.4.10 as the client, a certificate from any authority, its own included, for any name, and otherwise a certificate for the database server's name issued by any certificate authority in the system's trust store. The server converted the name for the client with the C runtime's conversion in the C locale, which gives an empty string for such a name, and then set no CA file at all, without an error, while certificate verification stayed on, so the client - MariaDB Connector/C, bundled on Windows and the distribution's on Linux - verified the certificate of a database server over the network against the system's trust store instead of the configured CA; Connector/C 3.4.2 to 3.4.10 (bundled on Windows in 6.3.4 to 6.3.6) went further and, with no CA file, took a certificate within its dates whose issuer it could not find, for any name, with neither its chain nor its name checked and no password proof, when the server offered first a sign-in method that hashes the password, which an attacker in the middle chooses (MariaDB's CONC-853, fixed in Connector/C 3.4.11), and Connector/C 3.4 accepted from a MariaDB 11.4 or later server a certificate the store did not vouch for when that server proved it held the account's password; on a connection it treats as local (127.0.0.1, ::1, a Unix socket, a named pipe, and localhost on Windows), Connector/C 3.4.1 and later checked neither the certificate's issuer nor its name, so that a local attacker able to stand in for the database server could present any certificate within its dates of its own making. The settings line of hmailserver --check-database still named the configured file, and the application log said the certificate had been checked. With MariaDB Connector/C 3.4.1 to 3.4.9 as the client - bundled on Windows in 6.3.4 to 6.3.6, and the client of Linux distributions that have not patched it - the missing CA file also met the precondition of CVE-2026-107819, so that a certificate issued for any other name by a trusted authority was enough to obtain the database password. On Linux the file was found only when the server ran on glibc under a locale whose character set holds the name's characters (a UTF-8 locale, or a legacy 8-bit one the system has, in whose bytes the file is then named); with no locale, LC_ALL=C or a locale the system lacks, and on Alpine (musl), the connection failed instead. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate. |
| CVE-2026-126609 | High | 2026-11-11 | Not applicable | No public exploit | Progressive Robot hMailServer 6.2.25 through 6.3.7 on Windows, with a PostgreSQL database, the connection's sslmode require, verify-ca or verify-full, and a root certificate file named by PostgreSQLSslRootCert (from 6.2.25) or, with TlsMode=verify-full and neither PostgreSQL key set, by TlsCaFile (from 6.3.4), hands the file's name to libpq as bytes in the system's ANSI code page (up to 6.3.5 as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF), and libpq looks for the file by those bytes and then hands the same bytes to OpenSSL, whose file opening on Windows reads a name as UTF-8 first and opens the file at that reading when one is there. When every byte of the name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9 on code page 1252, which are U+00E9 in UTF-8 - the database server's certificate was checked against the file at that other name whenever one was there, which allows a local attacker who can create that file but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, or beside a folder directly under the system drive's root whose permissions the administrator restricted, and who can intercept the connection to the database server or stand in for it, to have hMailServer trust a certificate authority of the attacker's own and read and modify the traffic between hMailServer and its database, the database password included; the file alone, holding no authority that issued the database server's certificate, stops hMailServer from connecting to its database. The same applies in 6.3.4 through 6.3.7 to TlsCaFile when an Oracle MySQL client library has been put in place of the bundled MariaDB Connector/C, since that client opens the file through OpenSSL in the same way; the bundled MariaDB Connector/C opens the file in the code page and is not affected, and neither are the Linux builds. The configuration is not the default: by default no root certificate file is named. |
| CVE-2026-126232 | High | 2026-11-11 | Not applicable | No public exploit | A improper certificate validation vulnerability in Fortinet FortiAnalyzer 8.0.0 through 8.0.1, FortiAnalyzer 7.6.0 through 7.6.7, FortiAnalyzer 7.4.0 through 7.4.11, FortiAnalyzer 7.2 all versions, FortiAnalyzer Cloud 8.0.1, FortiAnalyzer Cloud 7.6.0 through 7.6.7, FortiAnalyzer Cloud 7.4.1 through 7.4.11, FortiAnalyzer Cloud 7.2 all versions, FortiManager 8.0.0 through 8.0.1, FortiManager 7.6.0 through 7.6.7, FortiManager 7.4.0 through 7.4.11, FortiManager 7.2 all versions, FortiManager Cloud 8.0.1, FortiManager Cloud 7.6.0 through 7.6.7, FortiManager Cloud 7.4.1 through 7.4.11, FortiManager Cloud 7.2 all versions may allow a MITM attacker to impersonate the radius server via a rogue RADIUS server. |
| CVE-2026-121528 | High | 2026-11-11 | Not applicable | No public exploit | A improper certificate validation vulnerability in Fortinet FortiOS 7.6.0 through 7.6.4, FortiOS 7.4.0 through 7.4.9, FortiOS 7.2.0 through 7.2.13, FortiOS 7.0 all versions, FortiOS 6.4 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the SSLVPN web portal and the backend destination website. |
| CVE-2026-125336 | High | 2026-11-10 | Not applicable | Proof of concept only | Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.3, pki.verifyCertificateChain() in lib/x509.js does not decode or enforce the X.509 nameConstraints extension while validating certificate paths. A name-constrained certificate authority with a non-critical extension can therefore issue a leaf certificate with a subjectAltName dNSName or subject commonName outside a permitted subtree or inside an excluded subtree, and node-forge accepts the chain. Exploitation requires a name-constrained CA that chains to a trusted root and either its private key or the ability to obtain an out-of-scope certificate, allowing impersonation of names outside the delegated namespace, including against forge.tls clients. Chains without nameConstraints are not affected, and affected versions safely reject critical nameConstraints as unsupported rather than accepting them. This issue is fixed in version 1.4.3. |
| CVE-2026-17333 | High | 2026-11-07 | Not applicable | No public exploit | IBM API Connect 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 could allow a remote attacker to bypass authentication and inject unauthorized configuration changes due to improper certificate validation. |
| CVE-2026-17332 | High | 2026-11-07 | Not applicable | No public exploit | IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to bypass security restrictions due to improper certificate validation. |
| CVE-2026-17309 | High | 2026-11-07 | Not applicable | No public exploit | IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to obtain sensitive information and tamper with configuration due to improper certificate validation. |
| CVE-2026-123306 | High | 2026-11-06 | Not applicable | No public exploit | In JetBrains IntelliJ IDEA before 2026.3 improper checks allowed server certificates to be added to the trust store during headless runs |
| CVE-2026-96453 | High | 2026-11-05 | No exploit published | No public exploit | A flaw was found in the Keycloak Admin CLI kcadm tool, which is used by administrators to manage Keycloak servers from the command line. When a custom truststore is provided to verify the server identity, the tool incorrectly accepts any self-signed certificate as long as the hostname matches. This allows a network attacker to impersonate the Keycloak server, steal administrative credentials, and perform unauthorized management actions. |
| CVE-2026-122318 | High | 2026-11-05 | Not applicable | No public exploit | Kyverno before 1.19.2 contains an authentication bypass in matchCertificateData that skips verifyImages subject and subjectRegExp checks when the signing certificate has no Subject Alternative Name. Attackers holding a leaf certificate from a configured private trust root can omit the SAN, set the expected Fulcio issuer OID, and sign malicious images that are admitted despite signer pinning. |
| CVE-2026-116789 | High | 2026-11-05 | Not applicable | No public exploit | FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, dtls_state_setup() compared a peer certificate with the SDP a=fingerprint only when FreeSWITCH was the DTLS client, not when it held the DTLS server role. An unauthenticated peer able to reach the negotiated media port could complete the DTLS-SRTP handshake with an unrelated certificate, obtain the leg's SRTP keys, decrypt and inject media, and displace the legitimate endpoint; on ICE-enabled legs the peer also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path. WebRTC and SIP DTLS-SRTP legs are affected whenever the peer selects the active role, while FreeSWITCH client-role handshakes already perform fingerprint validation. Version 1.11.2 introduces the remediation, which requires rtp_dtls_client_cert_verify_mode=fingerprint. |
| CVE-2026-109408 | High | 2026-11-05 | Protected by Waratek | No public exploit | vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0. |
| CVE-2026-54372 | High | 2026-11-04 | Not applicable | Proof of concept only | VitaFit Android application (com.vt.vitafit) before 2.8.1.0 contains an insecure TLS/SSL certificate validation vulnerability that allows network-based attackers to intercept and modify HTTPS traffic by exploiting a custom X509TrustManager that trusts all certificates and a hostname verifier that accepts any hostname. Attackers can perform a man-in-the-middle attack to capture account sessions and health-related API data, and use a captured session to delete the account's authentication record and prevent legitimate login. |
| CVE-2026-121147 | High | 2026-11-04 | Not applicable | No public exploit | This vulnerability exists in the iRA 2.0 and iRA.ev mobile applications due to improper implementation of SSL certificate pinning in the network security configuration, resulting in ineffective certificate pinning controls. An attacker positioned to intercept network traffic could exploit this vulnerability to intercept or modify communications between the application and its backend services. |
| CVE-2026-95751 | High | 2026-11-03 | Not applicable | No public exploit | An improper certificate validation vulnerability in the API of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to circumvent existing authentication controls if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to gain unauthorized access to the affected system. |
| CVE-2026-95750 | High | 2026-11-03 | Not applicable | No public exploit | An improper certificate validation vulnerability in HPE Networking Fabric Composer could allow an unauthenticated remote attacker to access sensitive information if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to obtain sensitive information, including credentials. |
| CVE-2026-95740 | High | 2026-11-03 | Not applicable | No public exploit | An improper certificate validation vulnerability in HPE Networking Fabric Composer could allow an unauthenticated adjacent attacker to intercept communications between the affected system and remote servers if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to obtain sensitive information. |
| CVE-2026-95736 | High | 2026-11-03 | Not applicable | No public exploit | Improper certificate validation vulnerabilities exist in the affected interface of HPE Networking Fabric Composer, which could be exploited by an unauthenticated adjacent attacker if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to intercept sensitive information. |
| CVE-2026-95735 | High | 2026-11-03 | Not applicable | No public exploit | An improper certificate validation vulnerability exists in HPE Networking Fabric Composer. Successful exploitation could allow an unauthenticated remote attacker, under certain preconditions outside the attacker's control, to obtain sensitive information, including credentials. |
| CVE-2026-95724 | High | 2026-11-03 | Not applicable | No public exploit | An improper certificate validation vulnerability exists in HPE Networking Virtual Intranet Access (VIA). Successful exploitation could allow an unauthenticated remote attacker to bypass authentication mechanisms, leading to the possible disclosure of sensitive information. |
| CVE-2026-121624 | High | 2026-11-03 | Not applicable | No public exploit | Nanosystems Supremo for Windows and macOS before 5.0.2.3874 contains an improper certificate validation vulnerability that allows adjacent attackers to intercept TLS connections by presenting untrusted certificates. Attackers on the same network can terminate and relay the client's TLS session using self-signed certificates to read usernames, SHA-256 password hashes, and license codes. |
| CVE-2026-121565 | High | 2026-11-03 | Not applicable | No public exploit | Tanium addressed an improper certificate validation vulnerability in multiple products. Products have been updated to distrust several intermediate CA certificates associated with compromised private keys. |
| CVE-2026-121452 | High | 2026-11-03 | Not applicable | No public exploit | bbs-go through 4.4.6 contains an improper certificate validation vulnerability that allows network-positioned attackers to intercept SMTP traffic because sendEmail() sets InsecureSkipVerify to true. Attackers can present any certificate to capture SMTP PLAIN auth credentials and read or modify outgoing password-reset and verification emails. |
| CVE-2026-115714 | High | 2026-11-03 | Not applicable | No public exploit | Improper Certificate Validation (CWE-295) in the operating system certificate bundle shipped in the Docker images of APM Server; Auditbeat, Filebeat, Heartbeat, Metricbeat and Packetbeat; Elastic Agent, including Fleet Server and Cloudbeat; Logstash, for TLS connections that use the operating system certificate bundle; Elastic connectors; Universal Profiling (host agent, collector and symbolizer); and Elastic Maps Server. This certificate bundle, a dependency of these products (Dependency on Vulnerable Third-Party Component, CWE-1395), could allow an attacker to intercept or modify TLS-protected traffic via Signature Spoofing by Key Theft (CAPEC-474). The certificate bundle includes root certificate authorities that signed eight eMudhra intermediate certificate authorities whose private keys are compromised. Anyone with these keys can issue a certificate for any host name that these products accept as trusted. Exploitation requires an attacker in a network position between the product and the remote party, who presents a certificate issued with one of the compromised keys. |
| CVE-2026-118147 | High | 2026-10-31 | Not applicable | No public exploit | Improper certificate validation in Visual Studio allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2026-117681 | High | 2026-10-31 | Not applicable | No public exploit | A flaw was found in konflux-ci. This vulnerability allows privilege escalation when the user interface proxy automatically disables Transport Layer Security (TLS) certificate verification for connections to internal backend services in environments lacking a default service certificate authority. Because the proxy attaches a cluster-scoped authentication token with user impersonation rights to these requests, an adjacent network attacker capable of intercepting traffic can capture the credentials to gain full administrative control of the cluster. |
| CVE-2026-119559 | High | 2026-10-30 | Not applicable | Proof of concept only | OpenLiteSpeed through 1.9.4 contains an authentication bypass vulnerability that allows unauthenticated remote attackers to evade virtual host client certificate requirements over HTTP/3. Because QuicStream inherits a verifyContext() implementation that always returns true, attackers can present a non-mTLS host's SNI with a protected Host header to access protected content. |
| CVE-2026-92744 | High | 2026-10-29 | Not applicable | No public exploit | Under certain conditions, privilege manager agent allows a remote unauthenticated attacker to execute arbitrary code as LocalSystem. |
| CVE-2026-119190 | High | 2026-10-29 | Not applicable | Proof of concept only | Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge parsed deprecated extension OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. Exploitation requires a CA trusted by the application to issue a certificate carrying an attacker-supplied deprecated-OID extension, commonly because the CA copies extensions from a certificate signing request. By placing a permissive deprecated extension before the genuine 2.5.29.19 basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names, enabling server or client impersonation. If the issuing CA adds a keyUsage extension without keyCertSign, node-forge rejects the chain. This issue is fixed in version 1.4.1. |
| CVE-2026-119118 | High | 2026-10-29 | Not applicable | Proof of concept only | Crawl4AI before 0.9.5 contains an improper certificate validation vulnerability that allows network attackers to intercept crawls because Chromium always launches with --ignore-certificate-errors. Man-in-the-middle or DNS-controlling attackers can serve forged content to the crawler and read cookies and headers sent, while hard-coded --no-sandbox also overrides CRAWL4AI_CHROMIUM_SANDBOX. |
| CVE-2026-117611 | High | 2026-10-29 | Not applicable | No public exploit | Improper certificate validation in Checkmk <2.5.0p18, <2.4.0p39, <2.3.0p52 and 2.2.0 (EOL): the Certificate Authority stores bundled with "certifi" and "webpki-roots" include a root CA that trusts eMudhra (emSign) intermediate certificates whose private keys are public. |
| CVE-2026-118682 | High | 2026-10-28 | Not applicable | Proof of concept only | KaringX ClashMi through 1.0.32.1801 disables TLS certificate validation by default in the HttpUtils helper, allowing attackers to intercept HTTPS traffic by presenting any certificate. Attackers operating the user's proxy node can serve a forged update manifest omitting sha256 to deliver a malicious installer, achieving code execution when the update runs. |
| CVE-2026-118040 | High | 2026-10-28 | Not applicable | No public exploit | In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, improper verification of cryptographic signatures and improper certificate validation in RadPdfProcessing digital signature validation allow an unauthenticated attacker to cause signature validation to report forged content as unmodified and its signing certificate as valid via a crafted signed PDF document. |
| CVE-2026-116641 | High | 2026-10-28 | Not applicable | No public exploit | The DB Tools rely on the TLS implementation in Golang’s standard library, which generally uses the system CA store. However, the crypto/x509 package also has its own internal denylist of known-bad CA certificates. Golang 1.27.3 adds the eMudhra certificates to this list. DB Tools version 100.19.0 was compiled with Golang 1.26.8, which does not include this check. The issue is resolved by updating to Golang 1.27.3 in DB Tools 100.20.0 |
| CVE-2026-111459 | High | 2026-10-27 | Not applicable | No public exploit | An improper certificate validation vulnerability exists in Moxa Remote Connect Suite (MRC Client). Under certain conditions, an unauthenticated attacker with on-path access to the communication between the MRC Client and its server could impersonate a trusted server and conduct a man-in-the-middle attack, potentially compromising the confidentiality and integrity of communications. |
| CVE-2026-115930 | High | 2026-10-26 | Not applicable | No public exploit | The MongoDB Shell (mongosh) relies on Node.js as a third-party runtime that carries its own TLS root certificate store. This certificate store has the recoverable eMudhra intermediate CA certificates. This issue impacts MongoDB Shell (mongosh) versions prior to 2.14.0 and can be resolved by updating to mongosh 2.14.0 which bundles Node.js 24.22.1 or later. If mongosh is installed through npm, it uses the Node.js runtime installed on the host; update that runtime separately. |
| CVE-2025-13833 | High | 2026-10-26 | Not applicable | No public exploit | A vulnerability exists in SecureConnector for Windows when the “Additional Appliance Connections” setting is enabled and the agent’s configuration file contains more than three trusted‑server entries. Some entries omit TLS certificate fingerprints, which allows the agent to accept and establish sessions with a malicious server. An attacker who controls the wired or wireless network can redirect traffic to a malicious server. The attacker can then use the agent’s built‑in command/file features to execute arbitrary commands as SYSTEM, granting full administrative control and the ability to disable endpoint protections or exfiltrate data. |
| CVE-2026-115929 | High | 2026-10-24 | Not applicable | No public exploit | MongoDB Compass relies on Electron, a third-party runtime that carries its own TLS root certificate store. This root certificate store has the recoverable eMudhra intermediate CA certificates. Issue is resolved by updating to Compass 1.53.1, which includes Electron 44.9.1. |
| CVE-2026-106069 | High | 2026-10-23 | Not applicable | No public exploit | A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as `0127.0.0.1`. `tls.checkServerIdentity()` normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (`0127.0.0.1` becomes `87.0.0.1`), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (`127.0.0.1`). A server at the connected address can then be authenticated with a certificate issued for another IP address. This vulnerability affects Node.js **26.x**, **24.x**, and **22.x**. |
| CVE-2026-105483 | High | 2026-10-23 | Not applicable | No public exploit | A flaw in Node.js TLS hostname verification allows a certificate without a matching IP address SAN to authenticate a connection to an IPv4 address when the host is written with non-ASCII characters, such as fullwidth digits (`127.0.0.1`). `tls.checkServerIdentity()` did not recognize such hosts as IP addresses, even though they normalize and resolve to a regular IPv4 address, and matched them against the certificate DNS names and Common Name instead. A certificate containing `DNS:127.0.0.1` or `DNS:*.0.0.1` could therefore be accepted for an IP endpoint it was not issued for. This is a regression introduced after the fix for CVE-2026-48618. This vulnerability affects Node.js **26.x** and **24.x**. |
| CVE-2026-114642 | High | 2026-10-22 | Not applicable | No public exploit | Traefik 2.11.0 before 2.11.58 and 3.0.0 before 3.7.14 stores its NTLM/Kerberos backend round tripper in a client-connection slot not keyed by ServersTransport, so one service's TLS client configuration is reused for another service's backend. An unauthenticated client can arm the slot via a backend issuing an NTLM or Negotiate challenge, then reach another service on the same keep-alive connection, bypassing its root CAs, server name, and certificate verification. |
| CVE-2026-114047 | High | 2026-10-21 | Not applicable | No public exploit | FreeRDP from 2.0.0 before 3.32.0 contains an improper certificate validation vulnerability in its proxy that accepts untrusted target TLS certificates when no verification module is configured. Network-positioned attackers can intercept the proxy's outbound connection and present a self-signed, wrong-hostname certificate to impersonate the RDP target and receive proxied session data. |
| CVE-2026-111815 | High | 2026-10-21 | Not applicable | No public exploit | Apache Traffic Server can resume a TLS session across SNI virtual hosts without re-verifying a client certificate required by the resumed host's verify_client STRICT policy. This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| CVE-2026-111814 | High | 2026-10-21 | Not applicable | No public exploit | Apache Traffic Server's default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one. This issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| CVE-2026-87865 | High | 2026-10-20 | Not applicable | Proof of concept only | When libcurl uses libssh2 with a hashed `known_hosts` file, an unrelated initial entry can cause host key validation to report a key *mismatch* as a *missing* key to the `CURLOPT_SSH_KEYFUNCTION` callback. |
| CVE-2026-113119 | High | 2026-10-20 | Not applicable | No public exploit | Improper certificate validation in Network in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to leak sensitive information via crafted network traffic. (Chromium security severity: High) |
| CVE-2026-112006 | High | 2026-10-18 | Not applicable | No public exploit | OpenTelemetry opentelemetry-exporter-otlp-proto-http 1.5.0 before 1.45.0 contains an improper certificate validation vulnerability that disables TLS verification when OTEL_EXPORTER_OTLP_CERTIFICATE variables are empty strings. Man-in-the-middle attackers can impersonate the collector to read or alter exported traces, metrics, and logs, including authentication headers from OTEL_EXPORTER_OTLP_HEADERS. |
| CVE-2023-32198 | High | 2026-10-15 | Not applicable | No public exploit | A vulnerability has been identified in Steve where by default it was using an insecure option that did not validate the certificate presented by the remote server while performing a TLS connection. This could allow the execution of a man-in-the-middle (MitM) attack against services using Steve. |
| CVE-2026-96222 | High | 2026-10-13 | Not applicable | No public exploit | Improper certificate validation in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2026-78556 | High | 2026-10-13 | Not applicable | No public exploit | A vulnerability has been identified in Industrial Edge App Publisher (All versions < V1.27.9). The affected software does not properly validate the server certificate when initiating a TLS connection. This allows an attacker to intercept and relay communication (Man-in-the-Middle attack) and to spoof a trusted entity by interfering in the communication path between the client and the intended server. |
| CVE-2026-108185 | High | 2026-10-13 | Not applicable | No public exploit | Improper certificate validation in the My Notes feature of certain Zoom Clients may allow an unauthenticated user to conduct an information disclosure via network access. |
| CVE-2026-108184 | High | 2026-10-13 | Not applicable | No public exploit | Improper certificate validation in certain Zoom Clients for Windows may allow an unauthenticated user to conduct an information disclosure via network access. |
| CVE-2026-108131 | High | 2026-10-13 | Not applicable | No public exploit | No cwe for this issue in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2026-100123 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-100122 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-100121 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-100118 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-84418 | High | 2026-10-12 | Not applicable | No public exploit | IBM DataStage on Cloud Pak for Data 5.4.0.0 can allow a man-in-the-middle attacker to present a forged TLS certificate, intercept the connection, and capture the IAM bearer Authorization header automatically attached by the session adapter. The captured token grants full platform-scope tenant API access, enabling the attacker to read and manipulate the victim's DataStage projects, flows, assets, and pipeline definitions. This is client-side SDK code running on the user's own machine, so exploitation requires an external network interceptor rather than a co-tenant in the shared cluster. |
| CVE-2026-109245 | High | 2026-10-12 | Not applicable | Proof of concept only | FreeRDP 3.0.0 before 3.32.0 contains an improper certificate validation vulnerability in freerdp_http_request() in libfreerdp/utils/http.c that completes TLS handshakes without verifying the server certificate chain. On-path attackers can impersonate login.microsoftonline.com in the Azure AD authentication flow to capture OAuth authorization codes and substitute the OpenID discovery document. |
| CVE-2026-78020 | High | 2026-10-09 | Not applicable | No public exploit | Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Denial of service, Information disclosure, and Remote execution. |
| CVE-2026-87425 | High | 2026-10-08 | Not applicable | No public exploit | An unauthenticated remote attacker can modify the TLS client trust store in Brocade ASCG versions before 3.5.0. By supplying an unauthorized Certificate Authority (CA) certificate to an unauthenticated management interface, the attacker can cause the system to trust unauthorized certificates, potentially enabling Man-in-the-Middle (MITM) attacks against outbound communications with managed switches and peer nodes. |
| CVE-2026-84032 | High | 2026-10-08 | Not applicable | No public exploit | IBM Guardium Data Protection 12.2.2 could allow a remote attacker to conduct a man-in-the-middle attack due to improper certificate validation. |
| CVE-2026-107318 | High | 2026-10-08 | Not applicable | No public exploit | @fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP or HTTPS server. In versions prior to 12.7.0, all of the built-in HTTPS transports override the secure default and set rejectUnauthorized to false, so the proxy does not verify the TLS certificate of the upstream even when the application points it at an https upstream in the default configuration. An on-path network attacker can therefore impersonate the configured HTTPS upstream, read the credentials and request bodies the proxy forwards, and return forged responses that the application trusts. The issue is fixed in @fastify/reply-from 12.7.0, and users should upgrade to 12.7.0 or later. As a workaround, pass an explicit rejectUnauthorized true on the transport, supply an already configured undici instance, or use the undici global agent. |
| CVE-2026-92543 | High | 2026-10-07 | Not applicable | No public exploit | 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-67270 | High | 2026-10-06 | Not applicable | No public exploit | 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-63697 | High | 2026-10-06 | Not applicable | No public exploit | 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-71889 | High | 2026-10-03 | No exploit published | No public exploit | 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-80443 | High | 2026-10-02 | Not applicable | No public exploit | 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 | 2026-10-02 | Not applicable | No public exploit | 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 | 2026-10-02 | Not applicable | No public exploit | 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 | 2026-10-02 | Not applicable | No public exploit | 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-15911 | High | 2026-10-01 | Not applicable | No public exploit | 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 | 2026-10-01 | Not applicable | No public exploit | 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-97687 | High | 2026-09-29 | Not applicable | No public exploit | 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. |
| CVE-2026-73594 | High | 2026-09-29 | Not applicable | No public exploit | Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, Versions prior to 5.36, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Information disclosure, Information tampering, and Protection mechanism bypass. |
| CVE-2026-101916 | High | 2026-09-28 | Not applicable | No public exploit | @grpc/grpc-js implements the core functionality of gRPC purely in JavaScript, without a C++ addon. Prior to 1.13.6 and 1.14.5, getAuthContext does not distinguish authorized from unauthorized peer certificates when server credentials set requireClientCertificate to false. When applications use the returned authentication context, they can treat an unauthorized certificate as authorized, causing improper authentication. @grpc/grpc-js-xds can reach this condition when RBAC authentication is enabled in affected configurations. This issue is fixed in version 1.14.5 and 1.13.6. |
| CVE-2026-93302 | High | 2026-09-27 | Not applicable | No public exploit | MatchTrustedPeer ignores the public key used, leading to forged CA clones passing verification. Affected builds are any that enable the macro WOLFSSL_TRUST_PEER_CERT and load CA certificates with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The peer must know the certificates being loaded to either of those APIs to take advantage of the issue. When OPENSSL_COMPATIBLE_DEFAULTS is also defined this widens the affected API to include all CA certificate loading. Both macros are defined when using autoconf builds such as (nginx, haproxy, stunnel, wpas, apache httpd, hitch, bind, rsyslog, ffmpeg, all, distro). When the certificate is listed as a trusted peer certificate the issue previously allowed for a malicious (D)TLS server to bypass authentication once knowing which CA’s the client would accept. This also affects mutual authentication cases where the client knows which CA’s the server has loaded. If building with any of these configurations and using (D)TLS where the loaded CA’s could be known and authentication of the peer is desired, users should either: update to the latest wolfSSL version, apply the fix patch, or use the configure flag --disable-openssl-compatible-defaults and not load CA’s with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert() to mitigate the issue. |
| CVE-2026-89102 | High | 2026-09-27 | Not applicable | No public exploit | In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a certificate authority without verifying that the certificate is actually authorized to act as one. This means that an attacker who possesses any certificate that chains to a CA trusted by the client (along with its private key) can forge certificates for arbitrary identities that will be accepted as valid by the client. The end entity certificate of the server is stored in the persistent trust store, affecting subsequent connections that reuse the context even when OCSP multi usage is not employed. Found by internal wolfSSL testing. |
| CVE-2026-100665 | High | 2026-09-26 | No exploit published | Proof of concept only | Netty versions from 4.2.11.Final before 4.2.18.Final contain an incomplete hostname verification fix in the QUIC certificate verification path when using a plain X509TrustManager. The BoringSSLCertificateVerifyCallback discards the SSLEngine for plain trust managers, preventing endpoint identification from running even when HTTPS verification is configured. Attackers on the network path can present a certificate chain for the wrong hostname that the plain trust manager accepts, bypassing hostname authentication for QUIC clients. |
| CVE-2026-84465 | High | 2026-09-25 | Not applicable | No public exploit | Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when Zammad checks the digital signature on an incoming S/MIME-signed email, it does not verify that the signing certificate is genuinely trusted, it only checks whether a certificate with a matching name is already stored in the system. An attacker can create their own certificate using the name of a real, previously trusted sender and use it to send a forged email. Zammad will display that email with the same "validly signed" indicator as a genuine message from the real sender, even though the attacker never had access to that sender's actual certificate or private key. This issue is fixed in version 7.1.2. |
| CVE-2026-82157 | High | 2026-09-24 | Not applicable | No public exploit | Dell ThinOS 10, versions prior to SecurityAddon_2605.10.2766_T10, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Protection mechanism bypass and Unauthorized access. |
| CVE-2026-91812 | High | 2026-09-23 | Not applicable | No public exploit | A vulnerability in Foxit PDF Editor/Reader’s update mechanism allows man-in-the-middle attackers to bypass certificate validation and package integrity checks, potentially enabling arbitrary code execution with system privileges. |
| CVE-2026-83964 | High | 2026-09-22 | Not applicable | No public exploit | Adobe Connect is affected by an Improper Certificate Validation vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue does not require user interaction. |
| CVE-2026-65129 | High | 2026-09-22 | Not applicable | No public exploit | NVIDIA Infrastructure Controller for Linux contains a vulnerability where an attacker could cause improper certificate validation. A successful exploit of this vulnerability might lead to information disclosure, data tampering, and denial of service. |
| CVE-2026-84975 | High | 2026-09-18 | Not applicable | No public exploit | PJSIP is a free and open source multimedia communication library written in C. In 2.17 and earlier, the OpenSSL and GnuTLS backends in pjlib/src/pj/ssl_sock_ossl.c and pjlib/src/pj/ssl_sock_gtls.c copy DNS SubjectAltName values with string functions that recalculate their length and truncate an embedded NUL byte. With server verification enabled through --tls-verify-server for the PJSIP TLS/SIPS transport, a certificate containing a DNS SubjectAltName formed from the target hostname prefix followed by an embedded NUL and an attacker-controlled suffix can therefore be accepted for the prefix hostname. An attacker who possesses such a certificate from a trusted issuer and can intercept the connection can impersonate the target server, complete the SIP session, and receive REGISTER credentials. The mbedTLS backend is not affected because it preserves the explicit string length. No fixed version is available as of this review. |
| CVE-2026-84081 | High | 2026-09-18 | Not applicable | No public exploit | IBM Guardium Data Protection 12.2 could allow a remote attacker to bypass security restrictions due to improper certificate validation. |
| CVE-2026-40539 | High | 2026-09-18 | Not applicable | No public exploit | An improper certificate validation vulnerability in Email API in Synology DiskStation Manager (DSM) before 7.2.1-69057-10, 7.2.2-72806-7 and 7.3.2-86009-2 allows man-in-the-middle attackers to read or write arbitrary files and conduct denial-of-service attacks. |