CVE-2026-89102: OCSP stapling v2 multi accepts non-CA chain certificates as issuers
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 HAVECERTIFICATESTATUSREQUESTV2 feature and calls wolfSSLUseOCSPStaplingV2(ssl, WOLFSSLCSR2OCSPMULTI, 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.
Affected Software
Event History
Frequently Asked Questions
Which clients are exposed to this issue?
Affected clients are wolfSSL versions 5.7.2 through 5.9.2 that enable HAVE_CERTIFICATE_STATUS_REQUEST_V2 and invoke wolfSSL_UseOCSPStaplingV2 with WOLFSSL_CSR2_OCSP_MULTI. The issue is client-side and requires use of multiple OCSP response stapling.
What does an attacker need to exploit the flaw?
The attacker needs a certificate and corresponding private key for any certificate that chains to a CA trusted by the client. The certificate does not need to be authorized as a CA; the affected client incorrectly accepts a non-CA certificate in the peer chain as an issuer.
Can the impact persist after a connection using OCSP multi stapling?
Yes. The server end-entity certificate is stored in the persistent trust store, so subsequent connections reusing that context can remain affected even when OCSP multi usage is not employed.