CVE-2026-93302: wolfSSL Authentication Bypass Vulnerability

CVE-2026-93302 Overview

CVE-2026-93302 is a certificate validation flaw in wolfSSL's trusted peer certificate matching logic [CWE-295]. The MatchTrustedPeer function compared only the subject name and Subject Key Identifier (SKID) of a presented certificate, ignoring the actual public key. An attacker who knows which Certificate Authority (CA) certificates a client or server has loaded can forge a clone of that CA and bypass authentication in (D)TLS handshakes. The flaw affects builds compiled with WOLFSSL_TRUST_PEER_CERT that load CAs via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). When OPENSSL_COMPATIBLE_DEFAULTS is also enabled, the issue extends to all CA certificate loading paths used by common autoconf builds.

Critical Impact
A malicious (D)TLS peer can bypass certificate authentication by presenting a forged certificate that shares the subject name and SKID of a trusted CA, defeating mutual TLS protections.

Affected Products

wolfSSL builds compiled with WOLFSSL_TRUST_PEER_CERT loading CAs via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert()
wolfSSL builds compiled with OPENSSL_COMPATIBLE_DEFAULTS (widens exposure to all CA loading)
Autoconf-based integrations: nginx, haproxy, stunnel, wpa_supplicant, Apache httpd, hitch, BIND, rsyslog, ffmpeg, and distribution packages built with the all or distro configurations

Discovery Timeline

2026-09-27 - CVE-2026-93302 published to the National Vulnerability Database (NVD)
2026-09-29 - Last updated in the NVD database

Technical Details for CVE-2026-93302

Vulnerability Analysis

The defect lives in wolfSSL's trusted peer certificate matching logic. When a peer presents a certificate chain, GetTrustedPeer() looks up a stored trusted peer entry using the certificate's subject name and SKID. MatchTrustedPeer() then compared only those identifiers against the stored entry. It never verified that the presented certificate's public key matched the trusted peer's public key, nor did it validate the signature on the certificate.

An attacker who learns which CA certificates a peer trusts can generate a self-signed certificate with the same subject name and SKID. The forged certificate carries an attacker-controlled key pair. Because MatchTrustedPeer() returns success on name and SKID alone, wolfSSL marks the peer as trusted and completes the (D)TLS handshake.

The flaw breaks both server authentication and mutual TLS. In mutual TLS deployments, a malicious client that knows the server's trust store can impersonate any authorized client identity.

Root Cause

The matching function in wolfcrypt/src/asn.c compared only the stored name, signature, and name constraints rather than cryptographically binding the trusted peer entry to a specific public key. Treating identifier equality as proof of authenticity violates the standard chain-of-trust model required by RFC 5280.

Attack Vector

The attack requires network access to the (D)TLS endpoint and prior knowledge of the CA certificates loaded into the target's trust store. No credentials or user interaction are needed. The attacker crafts a certificate with the same Subject and Subject Key Identifier extension as a trusted CA entry, signs it with their own key, and presents it during the handshake.

The upstream fix removes the MatchTrustedPeer() call entirely and relies on the full certificate verification path performed later in the handshake:

                    tp = GetTrustedPeer(SSL_CM(ssl), args->dCert);
                    WOLFSSL_MSG("Checking for trusted peer cert");

-                   if (tp && MatchTrustedPeer(tp, args->dCert)) {
+                   if (tp) {
                        WOLFSSL_MSG("Found matching trusted peer cert");
                        args->haveTrustPeer = 1;
                    }
-                   else if (tp == NULL) {
+                   else {
                        /* no trusted peer cert */
                        WOLFSSL_MSG("No matching trusted peer cert. Checking CAs");
                    }

Source: wolfSSL commit 22bcd51d

Detection Methods for CVE-2026-93302

Indicators of Compromise

Unexpected successful (D)TLS handshakes from peers whose certificates were not issued by the legitimate internal CA
TLS session logs showing peer certificates with duplicate Subject and Subject Key Identifier values but differing public keys or serial numbers compared to the known trusted CA
wolfSSL debug messages containing Found matching trusted peer cert for peers that should not be present in the trust store

Detection Strategies

Inventory all wolfSSL deployments and identify builds compiled with WOLFSSL_TRUST_PEER_CERT or OPENSSL_COMPATIBLE_DEFAULTS using wolfssl-config --cflags or build logs
Capture TLS handshake metadata at network boundaries and alert when a peer certificate's SPKI (Subject Public Key Info) hash does not match the pinned CA SPKI hash
Review application code for calls to wolfSSL_CTX_trust_peer_cert() and wolfSSL_trust_peer_cert() and flag them for review

Monitoring Recommendations

Forward TLS and application logs to a centralized analytics platform and build detections for mismatched certificate fingerprints against the expected CA set
Monitor outbound connections from services such as nginx, haproxy, stunnel, and wpa_supplicant for unexpected certificate rotations
Track changes to CA bundle files and build configurations in configuration management to detect introduction of vulnerable macros

How to Mitigate CVE-2026-93302

Immediate Actions Required

Upgrade affected wolfSSL deployments to the patched release containing commit 22bcd51d
Audit all build pipelines for WOLFSSL_TRUST_PEER_CERT and OPENSSL_COMPATIBLE_DEFAULTS and rebuild downstream packages (nginx, haproxy, stunnel, Apache httpd, BIND, and others) against the fixed library
Rotate any long-lived credentials or session tokens exchanged over (D)TLS sessions that may have been established with vulnerable peers

Patch Information

The fix is published in wolfSSL commit 22bcd51d553eaac1de37bee91fdac80cc47961e1. The patch removes the insufficient MatchTrustedPeer() shortcut in src/internal.c and simplifies the trusted peer bookkeeping in wolfcrypt/src/asn.c, forcing the handshake to perform full certificate validation against the loaded CAs.

Workarounds

Rebuild wolfSSL with --disable-openssl-compatible-defaults and remove calls to wolfSSL_CTX_trust_peer_cert() and wolfSSL_trust_peer_cert() from application code
Load CAs through the standard wolfSSL_CTX_load_verify_locations() interface so chain validation performs full signature verification
Implement certificate pinning at the application layer by comparing the peer certificate's SPKI hash to a known-good value before trusting the connection

bash

# Rebuild wolfSSL without the vulnerable defaults
./configure --disable-openssl-compatible-defaults \
            --disable-trusted-peer-cert
make && sudo make install

# Verify the installed version includes commit 22bcd51d
git -C /path/to/wolfssl log --oneline | grep 22bcd51d