wolfSSL EUVD-2026-39548

Exploitation requires the target application to be built with --enable-opensslextra (OPENSSL_EXTRA) AND to validate certificates by calling the OpenSSL-compat X509_verify_cert() with caller-supplied untrusted intermediate certificates (for the TLS deferred/manual-verification variant, --enable-sessioncerts is additionally required). Given that, no attacker authentication or user interaction is needed (PR:N/UI:N) and the attacker only needs to present a chain containing a single attacker-controlled intermediate as the anchor. Limiting factors that reduce real-world exposure: native wolfSSL TLS/DTLS and the default WOLFSSL_VERIFY_PEER handshake are not vulnerable, so the bug does not affect standard TLS server/client verification; only the specific compatibility-API verification flow (commonly S/MIME/CMS, code/firmware signing, JWT/JWS x5c, or manual TLS peer checks) is exposed.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 8.7 with a single high integrity impact (VI:H) and no confidentiality or availability impact, which matches the nature of the bug: it does not leak or destroy data, it defeats authentication of certificates. The network vector and no-privileges/no-interaction metrics reflect that a remote attacker only needs to present a crafted chain to a vulnerable verifier. The critical caveat is that exploitability is gated by application build and usage: it requires --enable-opensslextra AND an application calling X509_verify_cert() with untrusted intermediates (and --enable-sessioncerts for the deferred-TLS variant), so the CVSS network/no-privilege metrics describe the attacker's position but understate the deployment-specific precondition. Native wolfSSL TLS/DTLS and the default WOLFSSL_VERIFY_PEER handshake are NOT affected, which materially narrows the population at risk. No EPSS score, KEV listing, or POC was provided; the supplied source evidence is a regression test fixture set (untrusted_anchor certs) from the fix PR, not a weaponized exploit. Net: this is a genuinely high-severity authentication bypass for the specific subset of wolfSSL consumers using the OpenSSL-compat verification API, but a low real-world-priority issue for the much larger set of users relying on native TLS verification.

An attacker generates their own CA and uses it to sign a leaf certificate for a target identity (e.g. a firmware-signing identity or a JWS x5c subject), then presents the leaf together with their attacker-controlled CA as an untrusted intermediate to an application that verifies it via wolfSSL's X509_verify_cert(). Because the verifier lets the supplied intermediate anchor the path instead of requiring a configured root, the forged certificate is accepted, enabling certificate impersonation, forged code/firmware signatures, or spoofed signed messages. No POC was provided, but the fix PR ships ready-made fixture certificates (untrusted_anchor leaf/int-ca/alt-ca) demonstrating exactly such a chain.