CVE-2026-11999: wolfSSL X.509 Trust Chain Bypass in OpenSSL Compatibility Mode

Technical summary

CVE-2026-11999 is a path-depth exhaustion vulnerability in wolfSSL's X509_verify_cert() function, part of the OpenSSL compatibility layer (--enable-opensslextra). The flaw occurs in the certificate chain verification logic: when validating a trust chain, the verifier iterates through intermediates up to a maximum path depth (default 100). If the supplied chain exceeds this depth, the algorithm exhausts its depth counter while still processing untrusted intermediates, then returns success based on the last verified link rather than confirmation of reaching a trusted anchor. This breaks the fundamental security requirement that any valid certificate path must terminate at a configured trust anchor. Native wolfSSL TLS/DTLS connections using the standard verification path (WOLFSSL_VERIFY_PEER) are unaffected because they do not call this vulnerable code path.

Business impact

For organizations using wolfSSL in OpenSSL compatibility mode where applications perform manual certificate verification, this vulnerability creates a direct path for certificate spoofing attacks. An attacker can craft a certificate chain with depth exceeding the verifier's limit and present it as valid, potentially enabling man-in-the-middle interception of communications or impersonation of trusted entities. Organizations relying on wolfSSL for standard TLS operations face no direct risk. However, any custom application logic that defers or manually invokes X509_verify_cert() with untrusted intermediates is at risk.

Affected systems

wolfSSL libraries built with the --enable-opensslextra configuration option and applications that call X509_verify_cert() with caller-supplied untrusted intermediate certificates are affected. The vulnerability does not impact: wolfSSL builds without OpenSSL compatibility mode, standard TLS/DTLS handshakes using native wolfSSL APIs, or applications that do not perform manual certificate verification. Identify affected systems by checking build configuration flags and auditing code for explicit X509_verify_cert() invocations outside the normal TLS handshake flow.

Exploitability

Exploitability is conditional on two factors: first, the target application must be built with --enable-opensslextra, and second, it must call X509_verify_cert() with untrusted intermediates supplied by an attacker or untrusted source. An attacker must construct a certificate chain exceeding 100 levels (or the configured depth limit) without a path to a legitimate trust anchor. While creating such a chain is technically straightforward, exploitation requires both the vulnerable configuration and vulnerable calling patterns in the application layer. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) reflects network-accessible exploitation with no prerequisites and integrity impact.

Remediation

Patch wolfSSL to a version that corrects the path-depth exhaustion logic in X509_verify_cert(). Verify the fix against the vendor advisory for the specific patched version. Until patching is possible, mitigate by: (1) disabling --enable-opensslextra at build time if OpenSSL compatibility is not required, (2) avoiding manual calls to X509_verify_cert() and instead relying on wolfSSL's native TLS verification (WOLFSSL_VERIFY_PEER), and (3) if manual verification is necessary, implementing an additional check to confirm the final certificate in the chain is signed by a configured trust anchor before accepting it.

Patch guidance

Apply the patched version of wolfSSL that fixes the trust-chain validation logic in X509_verify_cert(). Coordinate patching with code review of any application logic that directly calls this function; such code may require refactoring to use wolfSSL's native TLS verification flow, which is not vulnerable. Test patched builds in a staging environment with both standard TLS operations and any custom certificate verification logic to confirm correct behavior.

Detection guidance

Monitor for exploitation by: (1) analyzing certificate chains in TLS logs for unusual depth or suspicious intermediate certificates from untrusted sources, (2) enabling verbose logging in wolfSSL builds to capture X509_verify_cert() return values and chain details, and (3) auditing application code for explicit calls to X509_verify_cert() to identify at-risk code paths. Look for applications accepting certificate chains without a verifiable path to a trust anchor, particularly in proxy, gateway, or custom authentication scenarios.

Why prioritize this

This vulnerability scores HIGH (CVSS 7.5) due to its network-accessible nature, low complexity, and direct integrity impact through certificate spoofing. However, practical risk depends on deployment context: organizations using wolfSSL for standard TLS are unaffected and can defer patching; those with OpenSSL compatibility mode and manual verification logic should prioritize remediation. The vulnerability does not appear in the CISA KEV catalog, suggesting limited active exploitation to date.

Risk score, explained

CVSS 7.5 reflects a network-accessible vulnerability (AV:N) with no attack complexity (AC:L), no privilege requirement (PR:N), and no user interaction (UI:N). The impact is scoped to integrity (I:H) with no confidentiality or availability loss. The HIGH severity is appropriate given that successful exploitation enables certificate spoofing, a foundational security control failure. However, the practical risk is modulated by the requirement for a specific build configuration and vulnerable application calling patterns; organizations without these factors face negligible risk.

Frequently asked questions