The vulnerability lies in the wolfSSL_X509_verify_cert() routine, where untrusted intermediate certificates supplied by the caller are not removed before the trusted‑store check is performed. As a result, an attacker can craft a chain that never reaches a configured trust anchor yet is accepted as valid. While native wolfSSL TLS/DTLS flows are unaffected, any application that uses X509_verify_cert() for manual or deferred peer verification—including S/MIME, CMS, code signing, or JWT/JWS processing—can be tricked into accepting an attacker‑controlled certificate. The flaw is independent of key type or algorithm and requires only a single untrusted intermediate.

wolfSSL wolfSSL builds that enable the OpenSSL compatibility layer ("--enable-opensslextra") and that invoke X509_verify_cert() with caller‑supplied untrusted intermediates are affected. Applications that use wolfSSL’s default TLS handshake mode (WOLFSSL_VERIFY_PEER) are not impacted certificates via "--enable-sessioncerts" and call X509_verify_cert() explicitly.

With a CVSS score of 8.7 the severity is high, though no EPSS score is available and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires an attacker to supply a malicious certificate chain that is processed by an application performing manual verification. If the application receives this chain from an untrusted source—such as a network connection or a user‑supplied file—the attacker could bypass certificate validation and obtain trust in a forged certificate. The exploit requires no special privilege on the vulnerable host and can be executed entirely from the application layer.