CVE-2026-89135 in wolfSSL
Summary
by MITRE • 09/27/2026
A failed X509_verify_cert call permanently plants an unverified attacker CA in the shared CertManager, bypassing certificate validation in every type-blind sibling consumer (native TLS, OCSP, CRL, direct CM verify). This affects version 5.8.4 through 5.9.2 of wolfSSL with the macros (OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY) defined or built with --enable-opensslextra and the application is specifically making calls to the X509_verify_cert function.
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 described represents a critical failure in certificate validation logic within specific builds of wolfSSL, impacting versions 5.8.4 through 5.9.2 when compiled with OPENSSL_EXTRA support and without disabling certificates or building for WOLF_CRYPT_ONLY mode. The core technical flaw resides in the X509_verify_cert function, which is designed to validate a chain of certificates against trusted roots. Under normal operation, this function ensures that every certificate in the chain is properly signed by an authority present in the trust store and has not expired or been revoked. However, due to a logic error during error handling, if the verification process fails for any reason, instead of discarding the partially validated state or returning an error without modifying global state, the implementation incorrectly inserts the unverified certificate chain into the shared CertManager cache. This action permanently plants an attacker-controlled Certificate Authority (CA) into the system's trust store, effectively whitelisting it for all future operations.
This flaw has severe operational implications because the compromised CA is stored in a shared context that persists across multiple TLS sessions and connection types. The vulnerability affects every type-blind sibling consumer within the wolfSSL ecosystem, including native Transport Layer Security (TLS) connections, Online Certificate Status Protocol (OCSP) checks, Certificate Revocation List (CRL) validations, and direct calls to certificate verification functions. Consequently, once an attacker can trigger this failure condition—typically by presenting a maliciously crafted or expired certificate during the initial handshake—the system will subsequently trust any certificate signed by that attacker-controlled CA without further validation. This bypasses fundamental security controls such as chain-of-trust enforcement and revocation checking, allowing for man-in-the-middle attacks where an adversary can impersonate legitimate servers with certificates issued by their rogue CA.
From a classification perspective, this vulnerability aligns closely with CWE-295 Improper Certificate Validation, specifically the failure to properly validate certificate chains or trust anchors. The mechanism of storing invalid state in a shared cache also reflects aspects of CWE-665 Improper Initialization and CWE-436 Interpretation Error, as the system misinterprets a failed verification attempt as a signal to update its trusted store rather than reject the input. In terms of adversary tactics, this flaw facilitates MITM attacks consistent with ATT&CK technique T1078 Valid Accounts or more specifically T1557 Adversary-in-the-Middle when used in conjunction with credential theft or network interception. The persistence of the rogue CA means that even if the initial attack vector is closed, the system remains compromised until the cache is cleared or the application restarts, depending on implementation details regarding session state management.
Mitigation strategies must address both immediate remediation and long-term architectural fixes. For users affected by this issue in versions 5.8.4 through 5.9.2, upgrading to a patched version of wolfSSL that corrects the error handling logic within X509_verify_cert is the primary solution. If an upgrade is not immediately feasible, applications should avoid relying solely on the shared CertManager for critical validation paths and instead implement explicit verification checks after every call to X509_verify_cert, ensuring that any non-zero return code results in immediate termination of the connection without caching the result. Additionally, developers should consider disabling OPENSSL_EXTRA compatibility mode if it is not strictly required by their application stack, as this reduces the attack surface related to OpenSSL API emulation bugs. Regular auditing of certificate validation logic and implementing strict timeout or cache-clearing policies can further mitigate the risk of persistent trust store corruption in production environments.