X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - Use-after-free in PQC hybrid key-share handling. This is an incomplete-fix follow-up to CVE-2026-5460
    (released in 5.9.1): a malicious TLS 1.3 server sending a truncated PQC hybrid KeyShare can still trigger
    the error cleanup path to operate on freed memory. (CVE-2026-7531)

  - Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted
    intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an
    intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility
    certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the
    X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled. (CVE-2026-6091)

  - When HAVE_ENCRYPT_THEN_MAC is configured, the implementation could fall back to MAC-then-Encrypt rather
    than enforcing Encrypt-then-MAC. (CVE-2026-6092)

  - Heap buffer overread in wc_PKCS7_DecodeEnvelopedData when parsing crafted PKCS7 EnvelopedData. This could
    theoretically be triggered by attacker-supplied data delivered via S/MIME or CMS. (CVE-2026-6094)

  - Bleichenbacher padding oracle in PKCS#7 KTRI decryption. When decrypting PKCS#7 EnvelopedData using RSA
    PKCS#1 v1.5 key transport, wolfSSL returned distinguishable error codes depending on whether RSA padding
    validation failed versus whether the decrypted content was malformed. An attacker able to submit crafted
    EnvelopedData messages and observe error responses could use this as a padding oracle to incrementally
    recover the encrypted Content Encryption Key (CEK). The fix generates a deterministic pseudo-random fake
    CEK on padding failure (via HMAC-SHA256) and proceeds with decryption identically, using constant-time
    operations throughout, so that all failure paths produce the same error regardless of padding validity.
    (CVE-2026-6291)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()).
    This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates     certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for     those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS     usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted     intermediate into the certificate manager but failed to drop them before the trusted-store check, so an     untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a     configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled     certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing,     JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices.
    The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing     manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.
    (CVE-2026-11310)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
474886	Alpine: multiple wolfssl packages: security update to 5.9.2-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	high
474886	Alpine: multiple wolfssl packages: security update to 5.9.2-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	high
323797	Linux Distros Unpatched Vulnerability : CVE-2026-11310	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-11310

high

Tenable Plugins

high

high

high