security/wolfssl: Update to 5.9.4HEADmain

Changes since 5.9.2:

To download the release bundle of wolfSSL visit the download page at
www.wolfssl.com/download/

PR stands for Pull Request, and PR references a GitHub pull request
number where the code change was added.

NOTE: liboqs is no longer used for any algorithm: Falcon now has a
native wolfCrypt implementation, and the liboqs dependency and its
configure and CMake options have been removed (see PQC below).
NOTE: Certificates carrying trailing bytes after the DER structure are
now rejected unless WOLFSSL_NO_ASN_STRICT is defined; only the
certificate itself is copied into WOLFSSL_X509.
NOTE: ABI: struct OcspRequest (exported as OCSP_REQUEST) loses its
trailing ssl pointer; consumers that embed the struct must be rebuilt.
NOTE: Under FIPS: HMAC-MD5 is rejected, AES-GCM encryption with an IV
shorter than 12 bytes returns FIPS_BAD_VALUE_E (override with
WC_FIPS_AESGCM_ALLOW_SHORT_NONCES), the CMAC minimum tag is 64 bits, and
RSA-PSS salts longer than the hash are refused (FIPS 186-5).
--enable-wolfclu no longer enables MD5, Ed25519 or ASN relaxation on
FIPS builds.

wolfSSL Release 5.9.4 (September 25, 2026)

Vulnerabilities

  * [High CVE-2026-93302] MatchTrustedPeer ignores the public key used,
    leading to forged CA clones passing verification. Affected builds
    are any that enable the macro WOLFSSL_TRUST_PEER_CERT and load CA
    certificates with wolfSSL_CTX_trust_peer_cert() or
    wolfSSL_trust_peer_cert(). The peer must know the certificates being
    loaded to either of those APIs to take advantage of the issue. When
    OPENSSL_COMPATIBLE_DEFAULTS is also defined this widens the affected
    API to include all CA certificate loading. Both macros are defined
    when using autoconf builds such as (nginx, haproxy, stunnel, wpas,
    apache httpd, hitch, bind, rsyslog, ffmpeg, all, distro). When the
    certificate is listed as a trusted peer certificate the issue
    previously allowed for a malicious (D)TLS server to bypass
    authentication once knowing which CA's the client would accept. This
    also affects mutual authentication cases where the client knows
    which CA's the server has loaded. If building with any of these
    configurations and using (D)TLS where the loaded CA's could be known
    and authentication of the peer is desired, users should either:
    update to the latest wolfSSL version, apply the fix patch, or use
    the configure flag --disable-openssl-compatible-defaults and not
    load CA's with wolfSSL_CTX_trust_peer_cert() or
    wolfSSL_trust_peer_cert() to mitigate the issue. The affected
    certificate verification path with (D)TLS is in wolfSSL versions
    5.3.0 to 5.9.2. Found via the Anthropic OSS program. Fixed in commit
    https://github.com/wolfSSL/wolfssl/commit/22bcd51d553eaac1de37bee91fdac80cc47961e1
  * [High CVE-2026-89102] In wolfSSL versions 5.7.2 through 5.9.2 there
    is a client-side implementation flaw in RFC 6961, multiple OCSP
    response stapling, which can lead to certificate forgery. When a
    wolfSSL client enables OCSP stapling with the
    HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls
    wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options),
    the client accepts any certificate in the peer's chain as a
    certificate authority without verifying that the certificate is
    actually authorized to act as one. This means that an attacker who
    possesses any certificate that chains to a CA trusted by the client
    (along with its private key) can forge certificates for arbitrary
    identities that will be accepted as valid by the client. The end
    entity certificate of the server is stored in the persistent trust
    store, affecting subsequent connections that reuse the context even
    when OCSP multi usage is not employed. Found by internal wolfSSL
    testing. Fixed in PR 11027.
  * [High CVE-2026-89136] When using RPK (Raw Public Key), the client
    side of a TLS 1.2, 1.3 and DTLS 1.2 connection could accept an
    unsolicited server_cert_type=RawPublicKey which allowed a malicious
    or misbehaving server to bypass authentication. RPK is off by
    default and only enabled in --enable-rpk OR --enable-all OR
    --enable-distro AKA HAVE_RPK builds. This affects versions 5.6.0 to
    5.9.2. Thanks to Christos Papakonstantinou (Cantina Security) for
    the report. Fixed in PR 11009.
  * [Med CVE-2026-93304] A (D)TLS 1.2 client can accept a
    ChangeCipherSpec message before it has sent its ClientKeyExchange.
    No master secret has been derived at that point, so the client
    installs read keys derived from a known (deterministic) key and
    checks the server's Finished against that same key. An out-of-order
    ChangeCipherSpec can therefore be used by an attacker to complete
    the handshake in place of the server and send data the client
    accepts as authentic. The client's own traffic still uses correctly
    derived keys, so the attacker cannot read it, and the genuine server
    never completes the handshake. DTLS 1.2 clients are exposed because
    a datagram read can deliver the out-of-order records on its own. TLS
    1.2 clients are exposed when the application supplies received bytes
    with wolfSSL_inject() or enables read ahead. For certificate suites,
    the attacker must be in a man-in-the-middle position. For PSK (Pre
    Shared Key) connections, any fake server can succeed without knowing
    the PSK. The affected versions of wolfSSL are from 4.7.0 to 5.9.2.
    Found via the Anthropic OSS program. Fixed in PR 11458.
  * [Med CVE-2026-89133] wolfSSL versions 5.9.2 and earlier contain a
    flaw in the X.509 certificate validation logic where it fails to
    properly enforce NameConstraints extensions when there is an
    unconstrained CA tier between a name-constrained intermediate CA and
    the leaf certificate. wolfSSL incorrectly accepted certificates for
    hostnames they shouldn't be allowed to cover, due to a chain-walking
    state-machine bug that resets the validation state when encountering
    an intermediate without NameConstraints, thereby bypassing
    cryptographic delegation controls. This defect exists in the default
    build configuration that makes use of certificates where name
    constraint extensions are used. Thanks to Jack Lloyd, PathDiff, and
    Ben Smyth for reporting the issue. Fixed in PR 10687.
  * [Med CVE-2026-89134] A certificate with no dNSName SAN but another
    SAN type present (e.g. registeredID or iPAddress) bypassed the
    Subject CN dNSName name-constraint check. The CN-as-DNS fallback was
    gated on cert->subjectCN != NULL && cert->altNames == NULL &&
    !cert->isCA instead of "no dNSName SAN", so an out-of-scope CN was
    accepted. This incomplete fix from CVE-2026-6731, leading to the
    name-constraint check issue, was introduced in wolfSSL version
    5.9.2. Thanks to Jorge Milla (Pig-Tail) for the report. Fixed in PR
    10837.
  * [Med CVE-2026-89135] A failed X509_verify_cert call permanently
    plants an unverified attacker CA in the shared CertManager,
    bypassing certificate validation in every type-blind sibling
    consumer (native TLS, OCSP, CRL, direct CM verify). This affects
    version 5.8.4 through 5.9.2 of wolfSSL with the macros
    (OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY) defined or built
    with --enable-opensslextra and the application is specifically
    making calls to the X509_verify_cert function. Thanks to Christos
    Papakonstantinou (Cantina Security) for the report. Fixed in PR
    11009.
  * [Low CVE-2026-15442] In all builds that make use of (D)TLS,
    including default builds, there is a series of conditional states
    during the TLS shutdown which could lead to a heap-use-after free.
    If an application ended up getting a partial wolfSSL_read() which is
    sometimes caused by a small user buffer passed in, then called
    wolfSSL_shutdown for a bidirectional close and attempted to
    wolfSSL_read() again while the peer continues trying to send data
    during the shutdown it would lead to a state where a potential
    heap-use-after free happened. This affects versions 4.4.0 through
    5.9.2 of wolfSSL. Thanks to the Fuzz0x team for the report. Fixed in
    PR 10863.
  * [Low CVE-2026-94417] When an application enables both OCSP and CRL
    revocation checking on one WOLFSSL_CTX or certificate manager,
    wolfSSL skips the CRL check for any peer certificate that carries no
    Authority Information Access OCSP URL, and accepts a certificate the
    loaded CRL lists as revoked. The soft-fail policy for a missing
    responder collapses the OCSP result onto success before the code
    decides whether the CRL fallback is still needed, so "no responder
    exists" becomes indistinguishable from "the responder answered
    good". Affected builds define both HAVE_OCSP and HAVE_CRL:
    --enable-ocsp --enable-crl directly, and implicitly --enable-all,
    --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy,
    --enable-stunnel, --enable-lighty, --enable-wpas,
    --enable-strongswan, --enable-mosquitto, --enable-jni,
    --enable-openvpn and --enable-krb. An application is affected only
    if it calls both wolfSSL_CTX_EnableOCSP() (or wolfSSL_EnableOCSP() /
    wolfSSL_CertManagerEnableOCSP()) and wolfSSL_CTX_EnableCRL() (or the
    equivalents) with a CRL loaded; an application that uses OCSP
    stapling alone through wolfSSL_CTX_EnableOCSPStapling() is not
    affected, because that sets up a separate OCSP instance. The defect
    sits in ProcessPeerCerts() and is reachable over TLS 1.0 through TLS
    1.3 and DTLS, both on a client verifying a server certificate and on
    a server verifying a client certificate under mutual or
    post-handshake authentication. When the skipped check falls on a
    chain certificate rather than the leaf, the unchecked intermediate
    is promoted into the certificate manager and stays a trusted signer
    for every later connection on that context, so an affected
    long-running process needs its WOLFSSL_CTX torn down and not only
    its library replaced. All wolfSSL versions from 5.9.2 and earlier
    are affected; on versions 5.9.1 and 5.9.2 the WOLFSSL_OCSP_CHECKALL
    configuration fails closed with OCSP_NEED_URL, which leaves
    wolfSSL_CTX_EnableOCSP() without CHECKALL as the exposed
    configuration on 5.9.2. Found via the Anthropic OSS program. Fixed
    in PR 11500.
  * [Low CVE-2026-94418] Under WOLFSSL_SMALL_CERT_VERIFY,
    ProcessPeerCertParse() runs the certificate signature check
    separately from the parse to keep peak memory down, then merges the
    two results, but it merged the signature result back only when the
    parse returned 0, so any parse error hid it. ParseCertRelative()
    reaches its validity-date, name-constraint and critical-extension
    checks only after ConfirmSignature() has passed, so splitting the
    signature check out inverts the precedence that makes "override date
    errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced
    anywhere. The attacker needs no key material from the real PKI and
    no CA compromise: a self-made certificate carrying the expected
    subject name, the trusted CA's subject as its issuer, arbitrary
    bytes where the signature goes, a validity window in the past and
    the attacker's own key pair is sufficient. Affected builds define
    WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set
    implicitly by any platform or preset header, and is not reachable
    from any CMake option; the autotools routes are
    --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and
    --enable-tinytls13=mutualauth, and
    examples/configs/user_settings_embedded.h reaches it through
    WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither
    --enable-all nor --enable-distro enables it at all. The application
    must additionally install a verify callback through
    wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with
    WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or
    ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in
    wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client
    -D selects. An application with no callback, or whose callback
    returns preverify for date errors, still fails the handshake, and
    wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report
    ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3
    are affected in both directions, and DTLS reaches the same function;
    where the forged certificate is a chain certificate the callback's
    consent causes it to be cached in the WOLFSSL_CTX certificate
    manager, so an exposed deployment must restart the context or the
    process rather than merely reconnect. Releases v3.15.5 through
    v5.9.2 are affected. Found via the Anthropic OSS program. Fixed in
    PR 11500.
  * [Low CVE-2026-94419] Without NO_SESSION_CACHE_REF,
    wolfSSL_get_session() does not return a session object but a
    ClientSession reference of the form {row, index, hash(sessionID)}
    into the process-global SessionCache, and ClientSessionToSession()
    validates it against that hash alone. Because the TLS 1.2 session ID
    is chosen by the server and sent in clear, AddSessionToCache()
    matches any other server's session on the same ID and overwrites the
    client-side entry with that server's master secret, cipher suite and
    version, while the handle continues to resolve; nothing on the write
    path compares the peer, the application's server ID or the
    WOLFSSL_CTX. Resuming through the handle then produces an
    abbreviated handshake in which no Certificate message is sent, so
    neither chain verification nor wolfSSL_check_domain_name() runs, and
    the attacker is accepted as the original server for the whole of
    that connection. Affected builds are those leaving
    NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE and
    TITAN_SESSION_CACHE all undefined, which includes a plain
    ./configure, --enable-opensslextra and --enable-opensslall; fifteen
    integration options define NO_SESSION_CACHE_REF and are therefore
    not affected, among them --enable-all, --enable-distro,
    --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel,
    --enable-wpas and the rest of the OPENSSL_COMPATIBLE_DEFAULTS
    family, and --enable-leanpsk, --enable-leantls, --enable-lowresource
    and --enable-tinytls13 disable the cache outright. The application
    must use the legacy reference flow, wolfSSL_get_session() or
    SSL_get_session() followed by wolfSSL_set_session();
    wolfSSL_get1_session() returns the session object itself and is not
    affected, nor are wolfSSL_SetServerID() lookups. Only TLS 1.2 and
    below and DTLS 1.2 and below are reachable, since TLS 1.3 and ticket
    resumption with an empty ServerHello session ID both use a
    client-chosen cache key. The poisoned entry lives in the
    process-global cache, so it crosses WOLFSSL_CTX boundaries and
    persists until the entry is evicted or the session times out, 500
    seconds by default. Releases v5.3.0 through v5.9.2 are affected; the
    fix adds a per-write generation counter to the cache and raises
    WOLFSSL_CACHE_VERSION from 2 to 3, so a cache persisted by an older
    build is rejected by a fixed one. Found via the Anthropic OSS
    program. Fixed in PR 11500.

Too many other changes to list; see the upstream release notes for
the full list of new features, behavioral changes, and bug fixes in
5.9.4:

https://github.com/wolfSSL/wolfssl/releases/tag/v5.9.4-stable

0 files changed, 0 insertions, 0 deletions