CVE-2026-93302: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-93302 is an authentication bypass vulnerability in wolfSSL's MatchTrustedPeer function, where the public key of a presented certificate is not verified during trusted peer matching, allowing forged CA clones to pass authentication checks. It affects wolfSSL versions 5.3.0 through 5.9.2 (inclusive) when built with the WOLFSSL_TRUST_PEER_CERT macro enabled and CA certificates loaded via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The vulnerability is significantly widened when OPENSSL_COMPATIBLE_DEFAULTS is also defined — a condition present in autoconf builds used by nginx, haproxy, stunnel, wpa_supplicant, Apache httpd, hitch, BIND, rsyslog, and ffmpeg. It carries a CVSS v4.0 base score of 8.3 (High) (GitHub Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation). The vulnerable MatchTrustedPeer() function matched a presented certificate against the trusted peer table using only the subject name hash, issuer hash, and Subject Key Identifier (SKID), then separately compared the certificate signature — but never verified the public key. This means an attacker who crafts a certificate reusing those metadata fields (subject name, issuer, SKID, and signature) but embedding a different public key could have it accepted as a trusted peer. The fix (commit 22bcd51) replaces the per-field comparison with a hash of the entire raw certificate DER (CalcHashId over cert->source/maxIdx), requiring byte-identical matching including the public key, and removes the now-redundant MatchTrustedPeer() function entirely (GitHub Advisory, wolfSSL Commit).

A malicious (D)TLS server that knows which CA certificates a client has loaded can forge a certificate clone — reusing the subject name, issuer, and SKID of a trusted CA — and bypass peer authentication entirely, establishing a fraudulent connection as a trusted peer. This also affects mutual TLS authentication scenarios where a malicious client knows which CAs the server has loaded. The primary impact is a high integrity compromise (unauthorized authentication), with a low confidentiality impact (potential exposure of data transmitted over the fraudulently established session); availability is not directly affected (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is 0.363%, indicating a low probability of exploitation in the near term. The vulnerability requires the attacker to have prior knowledge of which CA certificates the target has loaded (Attack Requirements: Present), which limits opportunistic exploitation. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify a target application using wolfSSL 5.3.0–5.9.2 built with WOLFSSL_TRUST_PEER_CERT and/or OPENSSL_COMPATIBLE_DEFAULTS (e.g., nginx, haproxy, stunnel, Apache httpd built with autoconf). Determine which CA certificates the target client or server has loaded as trusted peers — this may be discoverable through configuration files, documentation, or network traffic analysis.
2. Obtain a legitimate CA certificate: Acquire or observe the DER-encoded CA certificate that the target trusts via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert().
3. Forge a certificate clone: Craft a new certificate that reuses the subject name hash, issuer hash, SKID, and signature bytes of the trusted CA certificate, but embeds an attacker-controlled public key. In the vulnerable code, only these fields (not the public key) are compared during trusted peer lookup.
4. Initiate a (D)TLS handshake: Present the forged certificate to the target during a TLS or DTLS handshake, acting as a malicious server (or client in mutual TLS scenarios).
5. Bypass authentication: The vulnerable MatchTrustedPeer() logic accepts the forged certificate as a trusted peer, setting haveTrustPeer = 1 and skipping normal CA chain validation, allowing the attacker to establish a fraudulent authenticated session (GitHub Advisory, wolfSSL Commit).

Users should update to the latest wolfSSL version containing the fix (commit 22bcd51), which changes trusted peer matching to compare a hash of the entire raw certificate DER rather than individual fields. Alternatively, apply the fix patch referenced in GHSA-22fm-4q7r-f7w4. As a configuration-based workaround, build with the flag --disable-openssl-compatible-defaults and avoid loading CA certificates via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). Organizations using autoconf-based builds of nginx, haproxy, stunnel, Apache httpd, wpa_supplicant, hitch, BIND, rsyslog, or ffmpeg linked against wolfSSL should prioritize patching, as both WOLFSSL_TRUST_PEER_CERT and OPENSSL_COMPATIBLE_DEFAULTS are enabled by default in those configurations (GitHub Advisory).