CVE-2026-93302: Trusted peer certificate match ignores public key, allowing forged CA clones
MatchTrustedPeer ignores the public key used, leading to forged CA clones passing verification. Affected builds are any that enable the macro WOLFSSLTRUSTPEERCERT and load CA certificates with wolfSSLCTXtrustpeercert() or wolfSSLtrustpeercert(). The peer must know the certificates being loaded to either of those APIs to take advantage of the issue. When OPENSSLCOMPATIBLEDEFAULTS 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 wolfSSLCTXtrustpeercert() or wolfSSLtrustpeercert() to mitigate the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Build with the configure flag --disable-openssl-compatible-defaults, and do not load CA certificates with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert().
wolfSSL --disable-openssl-compatible-defaults = enabled
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Affected builds enable WOLFSSL_TRUST_PEER_CERT and load CA certificates through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). If OPENSSL_COMPATIBLE_DEFAULTS is also defined, all CA certificate loading is included; both macros are defined in autoconf builds.
What does an attacker need to exploit the authentication bypass?
The attacker must know the certificates loaded through the affected trusted-peer APIs, or the CA certificates loaded when OPENSSL_COMPATIBLE_DEFAULTS expands the affected scope. A malicious (D)TLS server can then bypass client authentication when the accepted CA is known, and the issue also applies to mutual-authentication scenarios where the client knows the server's loaded CA.
Are autoconf-based integrations affected by default?
Yes. The data states that WOLFSSL_TRUST_PEER_CERT and OPENSSL_COMPATIBLE_DEFAULTS are both defined when using autoconf builds, including nginx, haproxy, stunnel, wpas, Apache HTTP Server, hitch, bind, rsyslog, and ffmpeg.
What can be done if an immediate upgrade is not possible?
Apply the available fix patch or rebuild using the configure flag --disable-openssl-compatible. Updating to the latest wolfSSL version is also recommended.