CVE-2026-93302: Trusted peer certificate match ignores public key, allowing forged CA clones

Published Sep 27, 2026
·
Updated

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

1 affected component
wolfSSL wolfssl

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. 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

Sep 27, 2026
CVE Published
via MITRE·09:07 AM
Data Sourced
via MITRE·09:07 AM
DescriptionWeakness
Data Sourced
via NVD·10:16 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203