CVE-2026-89102: WolfSSL Authentication Bypass Vulnerability

CVE-2026-89102 Overview

CVE-2026-89102 is a certificate validation vulnerability [CWE-295] in wolfSSL versions 5.7.2 through 5.9.2. The flaw resides in the client-side implementation of RFC 6961 multiple Online Certificate Status Protocol (OCSP) response stapling. When a client enables OCSP stapling via wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), wolfSSL accepts any certificate in the peer chain as a certificate authority without verifying CA authorization. An attacker holding any certificate that chains to a trusted CA can forge certificates for arbitrary identities. The end-entity certificate is also persisted in the trust store, poisoning subsequent connections that reuse the context.

Critical Impact
Attackers with a valid leaf certificate chaining to a trusted CA can forge certificates for any hostname, enabling man-in-the-middle attacks against wolfSSL clients.

Affected Products

wolfSSL 5.7.2
wolfSSL versions 5.7.3 through 5.9.1
wolfSSL 5.9.2

Discovery Timeline

2026-09-27 - CVE-2026-89102 published to the National Vulnerability Database
2026-09-30 - Last updated in NVD database
Found by internal wolfSSL testing (specific discovery date not disclosed)

Technical Details for CVE-2026-89102

Vulnerability Analysis

The defect lies in how wolfSSL processes multi-stapled OCSP responses on the client side. RFC 6961 permits a TLS server to staple OCSP responses for every certificate in its chain. wolfSSL uses the certificates presented alongside these responses to validate signatures, but it fails to confirm that each certificate carries the cA:TRUE basic constraint or the keyCertSign key usage. As a result, any end-entity certificate presented in the chain is treated as if it were an issuing CA. An attacker who legitimately obtained a server certificate from any CA trusted by the victim can mint arbitrary end-entity certificates using the leaf's private key, and the client accepts the forged chain. The failure also writes the attacker's leaf certificate into the persistent trust store, so later TLS sessions sharing the WOLFSSL_CTX validate forged certificates even without OCSP multi usage.

Root Cause

The root cause is improper certificate validation [CWE-295] in the HAVE_CERTIFICATE_STATUS_REQUEST_V2 code path. wolfSSL does not enforce CA authorization checks on certificates used to verify stapled OCSP responses before promoting them into the trusted certificate cache.

Attack Vector

The attack requires network position to intercept TLS handshakes and possession of any certificate plus private key issued by a CA the victim trusts. The attacker configures a TLS server that advertises status_request_v2 and returns a chain containing the forged target certificate. Because the client treats the attacker's leaf as a signing CA, it validates the forged chain and establishes the session. Subsequent connections through the same context inherit the poisoned trust state.

See the wolfSSL fix in Pull Request #11027 for the authoritative description
of the vulnerable code path and the corrected CA authorization checks.

Detection Methods for CVE-2026-89102

Indicators of Compromise

TLS sessions in which the server certificate chain contains an end-entity certificate issuing another end-entity certificate.
Unexpected certificates appearing in the wolfSSL client's persistent trust store after sessions that negotiated status_request_v2.
Repeated TLS handshakes from wolfSSL clients to hosts whose certificates do not match historical issuer baselines.

Detection Strategies

Inventory applications linked against wolfSSL 5.7.2 through 5.9.2 and flag those that call wolfSSL_UseOCSPStaplingV2 with WOLFSSL_CSR2_OCSP_MULTI.
Compare observed server certificates against known issuer fingerprints using passive TLS monitoring to surface chains where non-CA certificates sign other certificates.
Correlate wolfSSL client telemetry with downstream authentication anomalies that would indicate an in-progress man-in-the-middle.

Monitoring Recommendations

Capture and retain TLS metadata (SNI, certificate chain hashes, issuer distinguished names) from wolfSSL clients for retrospective hunting.
Alert on new certificates added to wolfSSL trust stores outside of change windows.
Monitor for outbound TLS connections to unexpected endpoints following patch deployment to confirm clean state.

How to Mitigate CVE-2026-89102

Immediate Actions Required

Upgrade wolfSSL to a release that incorporates the fix from wolfSSL Pull Request #11027.
Audit application code for calls to wolfSSL_UseOCSPStaplingV2 with the WOLFSSL_CSR2_OCSP_MULTI option and disable the feature where it is not required.
Rotate any wolfSSL client contexts that may have cached attacker-supplied certificates and clear persistent trust store files.

Patch Information

The vendor fix is tracked in wolfSSL Pull Request #11027. The patch adds CA authorization verification before using an intermediate certificate to validate stapled OCSP responses and prevents end-entity certificates from being written into the trust store.

Workarounds

Disable multi-OCSP stapling by removing calls that pass WOLFSSL_CSR2_OCSP_MULTI and rely on single OCSP stapling (WOLFSSL_CSR2_OCSP) until upgrade.
Build wolfSSL without the HAVE_CERTIFICATE_STATUS_REQUEST_V2 compile-time option if RFC 6961 support is not required.
Pin expected server certificates or issuer public keys at the application layer to limit the impact of forged certificates.

bash

# Rebuild wolfSSL without multi-OCSP stapling support
./configure --disable-ocspstapling2
make && sudo make install