CVE-2026-93302 is a certificate verification flaw in wolfSSL. In builds that enable trusted peer certificates, matching ignored the public key, so a forged clone of a trusted certificate could pass. NVD scores it High (8.2). Update wolfSSL, apply the fix commit, or change the build options.
What's affected
The record says affected builds are those that enable the macro WOLFSSL_TRUST_PEER_CERT and load certificates with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). If OPENSSL_COMPATIBLE_DEFAULTS is also defined, the affected API widens to all CA certificate loading. The record notes that both macros are set by autoconf builds used for software such as nginx, haproxy, stunnel and Apache httpd, among others.
The weakness is CWE-295, improper certificate validation. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N.
We could not confirm a release number that contains the fix. The commit message on the project's repository describes the change, and the record says to update to the latest wolfSSL version. Check wolfSSL's release notes for the first version that includes the commit.
How to check if you're exposed
Find out whether wolfSSL is in your stack, directly or inside a package such as a web server, proxy or VPN component:
dpkg -l | grep -i wolfssl
rpm -qa | grep -i wolfssl
Then check your build options. For autoconf builds, the generated options header lists the macros that were defined, so look for WOLFSSL_TRUST_PEER_CERT and OPENSSL_COMPATIBLE_DEFAULTS. Search your own code for the two trust peer functions named above.
The record says the attacker must know which certificates the application loads, so applications where the trusted certificates are public, or can be learned, are the exposed case.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Update wolfSSL to the latest release, or apply the fix commit from the project, and rebuild anything that links it statically.
- If you cannot update, the record's mitigation is to configure with the flag to disable OpenSSL compatible defaults and to stop loading CAs through the two trust peer functions.
- Check packages that bundle wolfSSL for their own updates.
- Test mutual TLS and peer authentication after the update.
Why it matters
The project's commit message explains the cause. Trusted peer matching compared the certificate's subject hash, issuer hash and key identifier, then compared a signature, but never compared the public key. A crafted certificate that reuses those fields could pass without holding the real key. The fix stores and looks up trusted peers by a hash of the entire certificate, so a match must be byte-identical.
The effect is a failure of authentication. The record says a malicious TLS or DTLS server could bypass authentication once it knows which CAs the client accepts, and mutual authentication is affected in the same way. The KEV flag in the record is false and no source we read reports exploitation.
Quick check
Which wolfSSL release has the fix?
We could not confirm a version number. The fix is in a commit on the project's repository, and the record says to update to the latest version.
Am I affected if I do not use trusted peer certificates?
The record limits the issue to builds with that option that load certificates through the named functions, or all CA loading when OpenSSL compatible defaults are on.
Sources
Last reviewed: 18 October 2026.
