CVE-2026-11310: wolfSSL X.509 Certificate Verification Bypass (OpenSSL Extra Mode)

Technical summary

The vulnerability exists in wolfSSL_X509_verify_cert(), the OpenSSL-compatible certificate verification function available only in builds compiled with --enable-opensslextra. The function temporarily loads caller-supplied untrusted intermediate certificates into the certificate manager during chain validation but fails to remove them before checking against the configured trusted store. This allows an untrusted intermediate to be treated as a trust anchor. The flaw affects any application that calls X509_verify_cert() with intermediate certificates supplied by an untrusted source—the bypass is independent of key type, signature algorithm, or TLS version. Notably, wolfSSL's native TLS/DTLS stack and automatic peer verification (WOLFSSL_VERIFY_PEER) remain unaffected; only applications performing manual, deferred, or out-of-band certificate verification are vulnerable.

Business impact

Organizations using wolfSSL for certificate-dependent operations outside standard TLS negotiation face significant PKI integrity risk. S/MIME email verification, firmware/code signing validation, JWT token verification via x5c headers, and certificate-pinning implementations could all be subverted if they rely on the vulnerable API. A successful attack enables certificate forgery without access to private keys, potentially compromising supply chains, secure communications, and software integrity verification. The impact is limited to non-standard verification patterns; standard TLS connections remain protected.

Affected systems

Only wolfSSL libraries built with the --enable-opensslextra compile flag are vulnerable. Vulnerable applications must actively call X509_verify_cert() (the OpenSSL API wrapper) rather than using wolfSSL's native certificate handling. Manual peer verification via TLS (--enable-sessioncerts) or deferred certificate validation in non-TLS contexts amplifies risk. Applications using wolfSSL's default TLS handshake or not explicitly enabling OpenSSL extra compatibility are not affected. Organizations should audit their build configurations and certificate verification code paths.

Exploitability

Exploitation requires no authentication, user interaction, or special privileges—an attacker simply presents a malicious certificate chain. The attack surface depends entirely on application design: any process that validates untrusted certificates through the vulnerable API is at risk. No active KEV exploitation has been reported, but the simplicity of the attack (crafting a self-signed intermediate and presenting it in a chain) means this could be weaponized quickly if widely used integrations are identified. Network-based exploitation is possible for protocols like S/MIME and TLS with manual verification.

Remediation

Apply wolfSSL security updates as they become available from the vendor. During interim periods, applications should avoid manual X509_verify_cert() calls if possible and instead rely on wolfSSL's native certificate verification functions. For unavoidable manual verification scenarios, implement additional trust validation at the application layer (e.g., certificate pinning, serial number whitelisting, or issuer DN constraints). Disable --enable-opensslextra at build time if OpenSSL compatibility is not essential. Organizations with custom PKI implementations or S/MIME validators should prioritize patching.

Patch guidance

Monitor wolfSSL's security advisory channels for patched releases. Verify the vendor advisory for specific version numbers addressing this issue; patch deployment should be tested in a staging environment first, particularly for applications with critical certificate-validation workflows (code signing pipelines, supply chain verification). If a patch is not yet available, consider temporarily restricting untrusted certificate input or disabling the vulnerable code paths via conditional compilation or configuration changes.

Detection guidance

Search codebases for calls to X509_verify_cert() or similar OpenSSL-compatible verification functions, especially in non-TLS contexts (S/MIME, JWT validation, firmware signing). Monitor wolfSSL library usage in build configurations; confirm whether --enable-opensslextra is enabled. Review certificate validation logs for unexpected trust path resolutions or certificates from unexpected issuers. For deployed systems, inspect network traffic for anomalous certificate chains presented in TLS handshakes or other cryptographic protocols. Intrusion detection rules should flag certificates whose issuers do not match any known trusted roots.

Why prioritize this

A CVSS 7.5 (HIGH) score reflects the integrity impact of certificate forgery without authentication barriers. While the vulnerability is limited to non-default API usage, it affects a broad spectrum of cryptographic protocols and could compromise supply chains or secure communications in affected organizations. The absence of KEV inclusion to date suggests limited active exploitation, but this should not delay patch development or remediation. Organizations with S/MIME, code-signing, or JWT validation pipelines should prioritize investigation and patching; standard TLS users can defer if build configurations confirm OpenSSL extra is disabled.

Risk score, explained

CVSS 3.1 score of 7.5 (HIGH) is driven by: Network-accessible attack vector (AV:N), low complexity (AC:L), no privilege requirement (PR:N), no user interaction (UI:N), unchanged scope (S:U), and high integrity impact (I:H). The absence of confidentiality or availability impact prevents a critical rating. However, context matters: the 7.5 applies only to applications using the vulnerable API; native wolfSSL TLS users face no increased risk.

Frequently asked questions