CVE-2026-89102 in wolfSSL
Summary
by MITRE • 09/27/2026
In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a certificate authority without verifying that the certificate is actually authorized to act as one. This means that an attacker who possesses any certificate that chains to a CA trusted by the client (along with its private key) can forge certificates for arbitrary identities that will be accepted as valid by the client. The end entity certificate of the server is stored in the persistent trust store, affecting subsequent connections that reuse the context even when OCSP multi usage is not employed. Found by internal wolfSSL testing.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in wolfSSL versions 5.7.2 through 5.9.2 represents a critical failure in the implementation of RFC 6961, specifically regarding multiple OCSP response stapling. This flaw stems from an incorrect client-side validation logic when the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature is enabled and the application explicitly invokes wolfSSL_UseOCSPStaplingV2 with the WOLFSSL_CSR2_OCSP_MULTI option. In a correctly implemented TLS stack, during the certificate verification process, every certificate presented in the peer's chain must be rigorously validated to ensure it possesses the necessary authority attributes, such as the Basic Constraints extension indicating CA status and appropriate key usage permissions. However, wolfSSL fails to perform this critical check for intermediate certificates when processing multi-OCSP responses. Instead of verifying that each certificate in the chain is authorized to act as a Certificate Authority or an issuer, the library accepts any certificate provided by the peer as valid if it chains back to a root CA trusted by the client configuration. This fundamental oversight bypasses essential PKI validation steps, allowing certificates issued by unauthorized entities to be treated as legitimate trust anchors within that specific session context.
The operational impact of this flaw is severe, enabling remote attackers to perform certificate forgery attacks against clients using affected wolfSSL versions. An attacker who possesses any valid certificate and its corresponding private key can exploit this weakness if the certificate chains to a CA trusted by the victim client. By presenting such a certificate during the TLS handshake while OCSP stapling with multi-response is enabled, the attacker can forge certificates for arbitrary identities that will be accepted as authentic by the wolfSSL client. This effectively breaks the chain of trust, allowing man-in-the-middle attacks where the attacker impersonates legitimate servers without detection. The security model relies on the assumption that only authorized CAs can issue valid end-entity certificates; this vulnerability invalidates that assumption within the scope of OCSP multi-stapling sessions, potentially leading to data exfiltration, session hijacking, and loss of confidentiality for communications established with vulnerable clients.
A particularly concerning aspect of this vulnerability is its persistence beyond the immediate connection where it occurs. The flaw causes the end entity certificate presented by a malicious peer during an OCSP stapling exchange to be stored in the client's persistent trust store. This means that even if subsequent connections do not employ OCSP multi-stapling or use different TLS configurations, the compromised certificate remains trusted due to its presence in the local cache. This behavior amplifies the attack surface significantly, as a single successful exploitation can degrade the security posture of the client for all future interactions with any server presenting certificates that chain through this now-trusted malicious entity. The persistence mechanism transforms what might have been a transient session-based issue into a long-term compromise of the trust store integrity, requiring manual intervention or cache clearing to remediate depending on the specific deployment environment and storage implementation details within wolfSSL.
From a standards perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation, as the software fails to validate the certificate properly against its intended purpose and authority constraints. It also relates to CWE-347 Improper Verification of Cryptographic Signature if one considers that the acceptance of unauthorized issuers undermines the validity of signatures issued by those entities within the context of trust establishment. In terms of MITRE ATT&CK, this flaw facilitates techniques associated with T1078 Valid Accounts or more specifically impersonation attacks where an adversary uses forged credentials to gain access, although in this case it is digital certificates rather than user accounts being spoofed. The exploitation vector allows for unauthorized authentication bypasses that mimic legitimate traffic patterns, making detection difficult without deep packet inspection and certificate pinning mechanisms independent of the TLS stack's default validation logic.
Mitigation strategies should focus on immediate software updates and architectural adjustments. Users running wolfSSL versions 5.7.2 through 5.9.2 with OCSP stapling enabled must upgrade to a patched version where the chain verification logic for multi-OCSP responses has been corrected to enforce strict CA authority checks. For environments unable to patch immediately, disabling the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature or avoiding the use of wolfSSL_UseOCSPStaplingV2 with WOLFSSL_CSR2_OCSP_MULTI options can prevent exploitation until an update is applied. Additionally, implementing certificate pinning at the application layer provides a robust defense-in-depth measure that does not rely solely on the TLS stack's validation logic. Pinning ensures that only specific, expected certificates or public keys are accepted for critical services, thereby neutralizing the impact of any forged certificates even if they chain to trusted roots but lack proper CA authorization attributes in the context of the application's security policy. Regular auditing of trust stores and monitoring for unexpected certificate additions can also help detect potential compromises resulting from this vulnerability.