The vulnerability allows an intermediate CA certificate that declares CA:TRUE but lacks the keyCertSign usage to be accepted as a signing CA. When an application builds a certificate path with chain‑supplied temporary CAs (WOLFSSL_TEMP_CA), the library previously exempted these intermediates from the key usage check, permitting a rogue entity to produce a chain that satisfies verification while containing forged signatures. This weakness can let an attacker have its fabricated certificates trusted, enabling impersonation or man‑in‑the‑middle attacks against applications that rely on wolfSSL for TLS/SSL verification.

wolfSSL is affected. The issue exists only in builds that enable the OpenSSL‑compatibility path (X509_verify_cert / X509_STORE with OPENSSL_EXTRA/OPENSSL_ALL). In these builds, untrusted chain intermediates added as temporary CAs are vulnerable. Operator‑loaded root certificates (WOLFSSL_USER_CA) and self‑signed roots remain exempt, as does the native verification mode that never creates temporary CAs. The check applies only when a Key Usage extension is present; if it is absent the policy treats all usages as present per RFC 5280, so enforcement occurs only when extKeyUsageSet is true.

The CVSS score is 6.3, indicating moderate severity. EPSS data is not available, so the exploitation probability is unknown. The vulnerability is not listed in CISA’s KEV catalogue. The likely attack vector is remote, requiring an attacker to provide a manipulated certificate chain to an application that uses the vulnerable path. Exploitation does not grant local privilege escalation but subverts authentication, allowing a forged certificate to be considered valid, which could lead to traffic interception or unauthorized access. The check can be disabled by defining ALLOW_INVALID_CERTSIGN; if that macro is set, the problem becomes a configuration issue rather than a code defect.