Hi,
The following vulnerabilities were published for wolfssl.
CVE-2026-15442[0]:
| 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.
CVE-2026-89102[1]:
| 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.
CVE-2026-89133[2]:
| 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.
CVE-2026-89134[3]:
| 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.
CVE-2026-89135[4]:
| 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.
CVE-2026-89136[5]:
| 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.
CVE-2026-93302[6]:
| 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.
CVE-2026-93304[7]:
| 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.
CVE-2026-94417[8]:
| 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.
They all should be fixed in 5.9.4 latest, but please double-check.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-15442
https://www.cve.org/CVERecord?id=CVE-2026-15442
[1] https://security-tracker.debian.org/tracker/CVE-2026-89102
https://www.cve.org/CVERecord?id=CVE-2026-89102
[2] https://security-tracker.debian.org/tracker/CVE-2026-89133
https://www.cve.org/CVERecord?id=CVE-2026-89133
[3] https://security-tracker.debian.org/tracker/CVE-2026-89134
https://www.cve.org/CVERecord?id=CVE-2026-89134
[4] https://security-tracker.debian.org/tracker/CVE-2026-89135
https://www.cve.org/CVERecord?id=CVE-2026-89135
[5] https://security-tracker.debian.org/tracker/CVE-2026-89136
https://www.cve.org/CVERecord?id=CVE-2026-89136
[6] https://security-tracker.debian.org/tracker/CVE-2026-93302
https://www.cve.org/CVERecord?id=CVE-2026-93302
[7] https://security-tracker.debian.org/tracker/CVE-2026-93304
https://www.cve.org/CVERecord?id=CVE-2026-93304
[8] https://security-tracker.debian.org/tracker/CVE-2026-94417
https://www.cve.org/CVERecord?id=CVE-2026-94417
Regards,
Salvatore