The vulnerability originates from the WOLFSSL_SMALL_CERT_VERIFY feature in wolfSSL, which separates certificate signature verification from parsing to reduce peak memory usage. The library merges the two results, but mistakenly ignores a signature‑verification failure when the parsing step fails. Consequently a certificate that would normally fail signature validation can slip through if a parse error, such as an invalid date, occurs. This flaw allows an attacker to craft a self‑signed certificate that lists the trusted CA as the issuer, inserts arbitrary bytes into the signature field, and sets a validity window in the past. With a permissive verify callback that treats date errors as acceptable, the forged certificate can be accepted, effectively bypassing peer authentication.

The flaw affects any installation of the wolfSSL library in which the WOLFSSL_SMALL_CERT_VERIFY option is enabled. The option is off by default and not enabled through standard CMake configurations, but it can be activated through autotools flags or by defining WC_CFG_SMALL_CERT_VERIFY in the user settings header. Applications that link to such builds and employ a verify callback that allows date errors (for example, using the VERIFY_OVERRIDE_DATE_ERR implementation) are susceptible. The problem exists in wolfSSL’s TLS 1.2, TLS 1.3, and DTLS implementations for both client and server peer verification.

The CVSS score of 2.3 indicates low severity, and the vulnerability is not listed in CISA’s KEV catalogue. EPSS is currently not available, so no quantitative exploitation likelihood is provided. Despite its low score, the flaw does not require access to private keys or a compromised certificate authority. An attacker can simply generate a forged certificate with the trusted CA’s subject as the issuer, an invalid signature placeholder, and an expired validity period. If an application accepts such a certificate because its verification callback treats date errors as successful, the attacker can impersonate the peer or perform a man‑in‑the‑middle attack. The risk is therefore highly dependent on the deployment’s configuration—enabling the flag or allowing permissive date handling increases exposure, while disabling the flag or enforcing strict signature checks mitigates the threat.