Source: wolfssl Version: 5.9.2-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
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
