CVE-2026-89135: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-89135 is an improper certificate validation vulnerability in wolfSSL that allows a failed X509_verify_cert call to permanently plant an unverified attacker-controlled CA into the shared CertManager, bypassing certificate validation for all subsequent consumers including native TLS, OCSP, CRL, and direct CM verify operations. It affects wolfSSL versions 5.8.4 through 5.9.2 when built with the macros OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY defined, or compiled with --enable-opensslextra, and only when the application explicitly calls X509_verify_cert. Disclosed on September 27, 2026, it carries a CVSS v4.0 base score of 6.3 (Medium) (Github Advisory, Feedly).

The root cause is CWE-295 (Improper Certificate Validation): when wolfSSL_X509_verify_cert() fails, temporary CA issuers added during the verification attempt are not cleaned up from the shared CertManager, allowing an attacker-supplied CA to persist as a trusted anchor (Github Advisory). Because the CertManager is shared across all type-blind consumers (TLS handshakes, OCSP, CRL, and direct CM verify), any subsequent certificate validation operation will treat the rogue CA as trusted. Exploitation requires network access, high attack complexity, and specific preconditions: the target application must be built with --enable-opensslextra (or equivalent macros) and must directly invoke X509_verify_cert. The fix, merged in wolfSSL pull request #11009, ensures wolfSSL_CertManagerUnloadTempIntermediateCerts() is called unconditionally on exit from wolfSSL_X509_verify_cert(), preventing TEMP_CA entries from persisting (wolfSSL PR #11009).

Successful exploitation allows an attacker to install a malicious CA into the shared CertManager, causing all subsequent TLS handshakes, OCSP responses, and CRL checks performed by the application to accept certificates signed by the rogue CA as valid. This effectively breaks the chain of trust for the entire application process, enabling man-in-the-middle attacks, certificate forgery, and interception of encrypted communications. Confidentiality and integrity of data transmitted over TLS connections are at risk; availability is not directly impacted (Github Advisory, Feedly).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is approximately 0.207%, reflecting low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity and specific deployment preconditions (particular compile-time flags and direct use of X509_verify_cert), limiting the attack surface (Github Advisory).

1. Identify a vulnerable target: Locate an application using wolfSSL versions 5.8.4–5.9.2 built with --enable-opensslextra (or OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY) that directly calls X509_verify_cert.
2. Prepare a rogue CA certificate: Generate a self-signed CA certificate under attacker control that will be submitted to the target application for verification.
3. Trigger a failed verification: Submit the rogue CA certificate to the application in a context where X509_verify_cert is called and will fail (e.g., the certificate is not yet trusted). Due to the bug, the temporary CA is added to the shared CertManager but not removed on failure.
4. Rogue CA persists: After the failed call, the attacker's CA remains planted in the shared CertManager as a trusted anchor for all subsequent operations in the same process.
5. Forge certificates: Issue end-entity certificates signed by the rogue CA. These will now pass validation for all subsequent TLS handshakes, OCSP, and CRL checks performed by the application.
6. Conduct man-in-the-middle or impersonation attacks: Use the forged certificates to intercept or impersonate TLS-protected communications handled by the vulnerable application (wolfSSL PR #11009, Github Advisory).

• Network: Unexpected or self-signed CA certificates presented during TLS handshakes to/from the application; TLS sessions established with certificates issued by unknown or unrecognized CAs.
• Logs: Application logs showing repeated failed X509_verify_cert calls followed by successful TLS handshakes with previously untrusted certificate chains; OCSP or CRL validation succeeding for certificates that should be rejected.
• Process/Runtime: Anomalous certificate trust decisions within a long-running process after an initial certificate verification failure; unexpected acceptance of certificates signed by CAs not present in the configured trust store.

Upgrade wolfSSL to a version beyond 5.9.2, which includes the fix merged in pull request #11009 on August 11, 2026 (wolfSSL PR #11009). As a workaround, avoid building wolfSSL with --enable-opensslextra or ensure the OPENSSL_EXTRA macro is not defined if the application does not require OpenSSL compatibility. Applications that do not directly call X509_verify_cert are not affected by this specific vulnerability. Audit any application code that invokes X509_verify_cert to assess exposure and prioritize patching (Github Advisory).

The vulnerability was reported by Christos Papakonstantinou of Cantina Security, as credited in the wolfSSL pull request #11009 commit messages (wolfSSL PR #11009). No significant broader media coverage or notable social media commentary has been identified at this time.