wolfSSL CVE-2026-11999

Exploitation requires all of the following concrete prerequisites: the wolfSSL build must be compiled with --enable-opensslextra (the OpenSSL compatibility layer), the application must call X509_verify_cert()/wolfSSL_X509_verify_cert() for manual or deferred verification rather than relying on the native TLS handshake, the application must pass caller-supplied untrusted intermediate certificates into that verification, and the attacker must supply a certificate chain deeper than the verifier's maximum path depth (default 100) that never reaches a configured trust anchor. Limiting factors that reduce real-world risk: native wolfSSL TLS/DTLS and the default WOLFSSL_VERIFY_PEER handshake are explicitly not affected, so the standard TLS use case is safe; the bug only manifests in the non-default opensslextra manual-verification deployment mode; and the attacker must control or inject an oversized intermediate chain. Per CVSS PR:N/UI:N, no authentication or user interaction is required once an application is in the affected configuration.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N) scores 8.2 (High): network-reachable, no privileges, no user interaction, but with an explicit Attack Requirement (AT:P) and impact limited to integrity (VI:H) - there is no direct confidentiality or availability impact in the base metrics. The AT:P flag and the description align well: exploitation is gated behind a specific, non-default usage pattern (opensslextra compat build + manual/deferred verification via X509_verify_cert() with caller-supplied untrusted intermediates + an attacker chain deeper than 100), which meaningfully narrows the affected population versus the raw 8.2 score. No EPSS score was provided in the input, it is not in CISA KEV, and no POC was supplied, so this is not currently evidence of active or widespread exploitation. The realistic priority is high for the specific subset of deployments matching the affected configuration (where it is vendor-described as critical) and low for everyone else, including all native-TLS users. Note one conflict to verify: base metrics set VC:N, yet a successful certificate-acceptance bypass can enable downstream MITM that does affect confidentiality of the protected channel - the base score scopes only the direct integrity impact, so secondary confidentiality risk should be assessed in context.

An attacker who can present a certificate chain to a vulnerable application (for example a malicious TLS server or a service feeding certificates into an app that defers verification) crafts a chain of more than 100 untrusted intermediates terminating in an attacker-controlled leaf and no legitimate trust anchor. The application calls X509_verify_cert() with these caller-supplied intermediates, path building exhausts its depth budget before reaching any trusted root, and the function returns success, causing the attacker certificate to be accepted as trusted. No public exploit is identified at time of analysis, and per the CVSS vector the attack is network-reachable with no authentication but carries a specific attack requirement (the non-default compat-API usage).