CVE-2026-55964 wolfSSL Certificate Validation Bypass

Technical summary

In wolfSSL's OpenSSL-compatibility layer (X509_verify_cert / X509_STORE), untrusted intermediates added as temporary CAs (WOLFSSL_TEMP_CA) during certificate path construction were exempted from RFC 5280 compliance validation. Specifically, the Key Usage extension check requiring keyCertSign was not enforced on these chain-supplied intermediates, allowing a certificate asserting basicConstraints CA:TRUE but lacking the keyCertSign bit to be treated as a valid signing authority. The fix applies the keyCertSign requirement to temporary CAs while preserving exemptions only for operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots. The check is conditioned on the Key Usage extension being present (extKeyUsageSet); absent extensions imply all usages per RFC 5280. Native certificate verification paths and builds without OPENSSL_EXTRA/OPENSSL_ALL are unaffected. The vulnerability can be disabled by defining ALLOW_INVALID_CERTSIGN at build time.

Business impact

Organizations using wolfSSL in OpenSSL-compatible mode for TLS/SSL certificate validation face a reduced but material risk of accepting fraudulent or unauthorized intermediate certificates. The practical impact depends on application architecture: systems that rely on certificate chain validation to enforce authorization boundaries or trust decisions could be circumvented. Exposure is limited to builds with OPENSSL_EXTRA or OPENSSL_ALL enabled and chains containing attacker-controlled intermediates. For applications that do not handle untrusted chains or use native wolfSSL verification, risk is minimal.

Affected systems

wolfSSL versions prior to the fix are affected if compiled with OpenSSL compatibility features (OPENSSL_EXTRA or OPENSSL_ALL flags). Systems using native wolfSSL certificate verification (without OpenSSL emulation) and applications that do not process untrusted certificate chains are not vulnerable. Products embedding wolfSSL should verify their configuration flags and certificate handling patterns. Verify affected version numbers against the vendor advisory.

Exploitability

Exploitation requires an attacker to influence or inject a malicious intermediate certificate into a chain being validated by a vulnerable wolfSSL instance. The attack surface is network-reachable if the application accepts untrusted certificate chains from remote peers (common in TLS handshakes). No user interaction or special privileges are required. However, the attacker must craft a certificate that asserts CA:TRUE and is accepted by the target's trust anchor; the utility of such a certificate depends on downstream application logic. CVSS 5.3 (Medium) reflects network accessibility and integrity impact with no confidentiality loss and no denial of service.

Remediation

Apply the security patch from wolfSSL as soon as it is available and verified against your version. Review your build configuration: if OPENSSL_EXTRA or OPENSSL_ALL is unnecessary for your use case, disable it to eliminate the affected code path entirely. Applications not processing untrusted certificate chains or using native wolfSSL APIs are already protected. For short-term mitigation, defining ALLOW_INVALID_CERTSIGN at compile time disables the check, but this should only be used if you have alternate trust validation mechanisms in place.

Patch guidance

Identify your wolfSSL version and build configuration (check for OPENSSL_EXTRA, OPENSSL_ALL, and ALLOW_INVALID_CERTSIGN flags). Obtain the patched version from wolfSSL's official distribution channel and verify the patch against the vendor advisory to confirm the keyCertSign enforcement has been applied to WOLFSSL_TEMP_CA. Test the patched version in a staging environment, particularly validating certificate chains with intermediates lacking keyCertSign; such chains should now be rejected. If OPENSSL_EXTRA or OPENSSL_ALL is not required, rebuild without these flags to reduce attack surface. Roll out to production after validation.

Detection guidance

Monitor for certificate validation failures or rejections that correlate with the introduction of the patch. Examine server logs for TLS handshake errors related to intermediate certificate validation, particularly for intermediates with basicConstraints CA:TRUE but no keyCertSign extension. Passive network monitoring of certificate chains being transmitted can identify suspicious intermediates, though determination of CA:TRUE claims requires certificate inspection. Application instrumentation to log certificate chain details during validation can help identify whether your systems process untrusted chains and whether any currently-accepted chains contain the vulnerable configuration.

Why prioritize this

This vulnerability has a CVSS Medium severity (5.3) and is not on the CISA KEV list, suggesting limited active exploitation. However, the issue directly undermines certificate validation logic, a critical security control. Prioritization should be driven by your use of OpenSSL-compatible wolfSSL in security-sensitive applications and the presence of untrusted certificate chains in your threat model. If you use wolfSSL primarily for TLS and do not enable OpenSSL compatibility features, this is lower priority; if you embed wolfSSL in a custom PKI or certificate verification pipeline with OPENSSL_EXTRA enabled, prioritize patching.

Risk score, explained

The CVSS v3.1 score of 5.3 reflects: Attack Vector=Network (reachable over the network), Attack Complexity=Low (no special conditions), Privileges Required=None, User Interaction=None (attack is automatic), Scope=Unchanged, Confidentiality=None (no data exposure), Integrity=Low (trust boundary can be violated), Availability=None. The score is Medium because the attack requires a specific configuration (OpenSSL compatibility) and the attacker must influence or inject a certificate into a chain, limiting the breadth of impact.

Frequently asked questions