AI analysis
CVE-2026-93302 is an improper certificate validation flaw (CWE-295) in wolfSSL: MatchTrustedPeer ignores the public key on a trusted peer certificate, so a forged clone of a loaded CA can pass verification. It is triggered on (D)TLS connections when the build defines WOLFSSL_TRUST_PEER_CERT and CAs are loaded with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(); defining OPENSSL_COMPATIBLE_DEFAULTS, which autoconf and distro builds do, extends the bug to all CA loading. An attacker who knows which CAs the peer has loaded can bypass authentication as a malicious (D)TLS server, or as a client in mutual-authentication setups, undermining integrity of the session while confidentiality impact is limited. Affected users are those who build wolfSSL this way and rely on peer authentication, including optional wolfSSL backends for servers and tools such as nginx, HAProxy, stunnel, Apache httpd, BIND, and others named in the advisory. It is not on the CISA KEV list, no public proof-of-concept is known, and exploitation status is none known.
What to do: Upgrade to the latest wolfSSL release or apply the vendor fix patch. If you cannot update immediately, rebuild with --disable-openssl-compatible-defaults and do not load CA certificates through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(); then confirm peer authentication still rejects certificates that are not the exact trusted CA.
Affected
| wolfSSL | Builds with WOLFSSL_TRUST_PEER_CERT that load CAs via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(); all CA loading when OPENSSL_COMPATIBLE_DEFAULT |
Estimated exposure
largeOrder of 10,000–100,000+ wolfSSL (D)TLS deployments using autoconf/distro defaults or trust-peer-cert (exact count unknown) — No public install census or scan count is available; the estimate reflects wolfSSL’s use as an embedded and distro TLS library and the advisory’s statement that autoconf builds define both vulnerable macros, limited to deployments that…
Description
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.