AI analysis
In wolfSSL 5.8.4 through 5.9.2, a failed call to X509_verify_cert still permanently registers the attacker-supplied, unverified CA certificate into the process-wide shared CertManager. Any later type-blind consumer of that store — native TLS handshakes, OCSP and CRL checks, and direct CertManager verifications — will then accept certificates chaining to the attacker's CA, enabling man-in-the-middle impersonation of servers or clients. The bug only affects builds compiled with --enable-opensslextra (or with OPENSSL_EXTRA defined while certificates are enabled and WOLFCRYPT_ONLY is not) and only applications that actually call X509_verify_cert, ideally on attacker-controlled input during a failed verification. It is rated medium severity (CVSS 4.0: 6.3, CWE-295) because exploitation requires high attack complexity and that precondition. The flaw was fixed in wolfSSL 5.9.4; no public proof of concept exists and there is no evidence of exploitation in the wild.
What to do: Upgrade to wolfSSL 5.9.4 or later, which fixes this issue among 11 TLS security fixes. If an immediate upgrade is not possible, rebuild without --enable-opensslextra where OpenSSL compatibility is not required, or avoid calling X509_verify_cert and clear/restrict the shared CertManager between verifications of untrusted input. Embedded product vendors should check whether their firmware links wolfSSL 5.8.4-5.9.2 with OPENSSL_EXTRA and invokes X509_verify_cert, and ship patched firmware accordingly.
Affected
| wolfSSL (built with --enable-opensslextra, or OPENSSL_EXTRA defined with !NO_CERTS and !WOLFCRYPT_ONLY, in applications | 5.8.4 through 5.9.2 |
Estimated exposure
unknown (potentially large embedded install base, but the affected subset is uncountable) — wolfSSL ships as a library inside countless IoT, embedded, and appliance products and leaves no fingerprint that public internet scans can attribute to a specific version or build configuration, so there is no defensible count of systems…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.