CVE-2026-11999: 
OpenSSL vulnerability analysis and mitigation

CVE-2026-11999 is an X.509 trust-chain bypass vulnerability (path-depth exhaustion) in wolfSSL's OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). It affects wolfSSL versions 5.7.4 through 5.9.1 (inclusive) built with --enable-opensslextra where the application calls X509_verify_cert() with caller-supplied untrusted intermediates. Native wolfSSL TLS/DTLS usage and the default WOLFSSL_VERIFY_PEER handshake are not affected. The vulnerability was published on June 25, 2026, with a fix merged on June 12, 2026 and released in version 5.9.2. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.2 (High) (Github Advisory, wolfSSL PR).

The root cause is CWE-295 (Improper Certificate Validation): wolfSSL_X509_verify_cert() returned success based on the last verified link in the chain rather than requiring the chain to reach a configured trust anchor. When a supplied certificate chain exceeds the verifier's maximum path depth (default: 100), the path-building loop exhausts its depth budget while still traversing untrusted intermediates, then incorrectly accepts the chain as valid. The fix (PR #10674, merged June 12, 2026) enforces that a trusted anchor must be reached, rejects depth-exhausted chains with a failure, and also hardens the function against allocation failures that previously caused a fail-open condition and against stack pollution from caller-supplied intermediates being removed from the wrong stack (wolfSSL PR, Github Advisory). Exploitation requires the attacker to be in a position to present a crafted certificate chain to an application performing manual or deferred certificate verification via this API.

Successful exploitation allows an unauthenticated network attacker to present a certificate chain that never reaches a configured trust anchor, causing the application to incorrectly accept an attacker-controlled certificate as valid. This results in a complete bypass of X.509 certificate verification, undermining the integrity of TLS/DTLS connections in affected applications — for example, enabling man-in-the-middle attacks, impersonation of trusted servers, or acceptance of fraudulent client certificates. Confidentiality and availability are not directly impacted, but the integrity compromise can facilitate further attacks such as credential theft or session hijacking (Github Advisory, wolfSSL PR).

1. Identify target applications: Locate applications using wolfSSL versions 5.7.4–5.9.1 compiled with --enable-opensslextra that perform manual certificate verification via X509_verify_cert() with caller-supplied untrusted intermediates (e.g., custom TLS clients, IoT device management platforms, or embedded systems with deferred certificate validation).
2. Craft a deep certificate chain: Generate a certificate chain with more than 100 intermediate certificates (exceeding the default maximum path depth), none of which chain to a configured trust anchor. Each intermediate must be validly signed by the previous one, but the chain as a whole does not terminate at a trusted root CA.
3. Present the chain to the target: Initiate a TLS/DTLS connection or trigger the application's manual certificate verification flow, supplying the crafted deep chain as the untrusted intermediates to X509_verify_cert().
4. Bypass verification: The path-building loop exhausts its depth budget while still processing untrusted intermediates and returns WOLFSSL_SUCCESS without ever reaching a trust anchor, causing the application to accept the attacker-controlled certificate as valid.
5. Achieve objective: With certificate verification bypassed, the attacker can impersonate a trusted server (man-in-the-middle), present fraudulent client certificates, or intercept/modify encrypted communications depending on the application's use of the verified certificate (wolfSSL PR, Github Advisory).

• Network: Unusual TLS handshakes presenting certificate chains with an abnormally large number of intermediate certificates (>100); connections from unexpected or unknown certificate issuers that are accepted by the application despite not chaining to a known root CA.
• Logs: Application logs showing successful certificate verification for connections where the presented chain does not terminate at a configured trust anchor; TLS session establishment with certificates issued by unrecognized or self-signed intermediates.
• Application Behavior: Applications built with wolfSSL accepting certificates from entities not in the configured trust store; unexpected successful authentication by clients or servers presenting deep certificate chains.

The primary remediation is to upgrade wolfSSL to version 5.9.2 or later, which includes the fix merged in PR #10674 on June 12, 2026 (wolfSSL PR, wolfSSL Advisory). Organizations that cannot immediately upgrade should audit their applications to identify those compiled with --enable-opensslextra that call X509_verify_cert() with caller-supplied untrusted intermediates, and prioritize these for patching. As a workaround, applications can migrate certificate verification to native wolfSSL TLS/DTLS functionality (e.g., WOLFSSL_VERIFY_PEER), which is not affected by this vulnerability. Reducing or eliminating reliance on manual/deferred verification via the OpenSSL compatibility API also mitigates exposure.

Security news outlets including CyberSecurityNews, SecurityOnline, and VPNcentral covered the vulnerability as part of broader reporting on multiple wolfSSL 5.9.2 security fixes, with some headlines characterizing the issues as affecting "billions of servers and IoT devices" (CyberSecurityNews, SecurityOnline). Tenable published a Nessus plugin (ID 323799) for detection. Community discussion on Bluesky and CVE tracking platforms noted the disclosure shortly after publication. FreeBSD ports and Debian packaging repositories moved quickly to incorporate wolfSSL 5.9.2, reflecting active ecosystem response (wolfSSL PR).