wolfSSL 5.9.1 CVE and non-CVE fixes

[Solar Designer <solar () openwall com>]

Hi,

wolfSSL 5.9.1 was released on April 8, 2026 with many CVE fixes:

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

>     [Critical] CVE-2026-5194
>     Missing hash/digest size and OID checks allow digests smaller than
> allowed by FIPS 186-4 or 186-5 (as appropriate), or smaller than is
> appropriate for the relevant key type, to be accepted by signature
> verification functions, reducing the security of certificate-based
> authentication. Affects multiple signature algorithms, including
> ECDSA/ECC, DSA, ML-DSA, ED25519, and ED448. Builds that have both ECC
> and EdDSA or ML-DSA enabled that are doing certificate verification are
> recommended to update to the latest wolfSSL release. Thanks to Nicholas
> Carlini from Anthropic for the report. Fixed in PR 10131.
>
>     [High] CVE-2026-5264
>     Heap buffer overflow in DTLS 1.3 ACK message processing. A remote
> attacker can send a crafted DTLS 1.3 ACK message that triggers a heap
> buffer overflow. Thanks to Sunwoo Lee and Seunghyun Yoon, Korea
> Institute of Energy Technology (KENTECH). Fixed in PR 10076.
>
>     [High] CVE-2026-5263
>     URI nameConstraints from constrained intermediate CAs are parsed but
> not enforced during certificate chain verification in
> wolfcrypt/src/asn.c. A compromised or malicious sub-CA could issue leaf
> certificates with URI SAN entries that violate the nameConstraints of
> the issuing CA, and wolfSSL would accept them as valid. Thanks to Oleh
> Konko @1seal for the report. Fixed in PR 10048.
>
>     [High] CVE-2026-5295
>     Stack buffer overflow in PKCS7 ORI (Other Recipient Info) OID
> processing. When parsing a PKCS7 envelope with a crafted ORI OID value,
> a stack-based buffer overflow can be triggered. Thanks to Sunwoo Lee,
> Woohyun Choi, and Seunghyun Yoon (Korea Institute of Energy Technology,
> KENTECH). Fixed in PR 10116.
>
>     [High] CVE-2026-5466
>     wolfSSL's ECCSI signature verifier wc_VerifyEccsiHash decodes the r
> and s scalars from the signature blob via mp_read_unsigned_bin with no
> check that they lie in [1, q-1]. A crafted forged signature could verify
> against any message for any identity, using only publicly-known
> constants. Thanks to Calif.io in collaboration with Claude and Anthropic
> Research for the report. Fixed in PR 10102.
>
>     [High] CVE-2026-5477
>     Potential for AES-EAX AEAD and CMAC authentication bypass on
> messages larger than 4 GiB. An attacker who observes one valid
> (ciphertext, tag) pair for a >4 GiB EAX message can replace the first 4
> GiB of ciphertext arbitrarily while the tag still verifies. Thanks to
> Calif.io in collaboration with Claude and Anthropic Research for the
> report. Fixed in PR 10102.
>
>     [High] CVE-2026-5447
>     Heap buffer overflow in CertFromX509 via AuthorityKeyIdentifier size
> confusion. A heap buffer overflow occurs when converting an X.509
> certificate internally due to incorrect size handling of the
> AuthorityKeyIdentifier extension. Thanks to Calif.io in collaboration
> with Claude and Anthropic Research for the report. Fixed in PR 10112.
>
>     [High] CVE-2026-5500
>     wolfSSL's wc_PKCS7_DecodeAuthEnvelopedData() does not properly
> sanitize the AES-GCM authentication tag length received and has no lower
> bounds check. A man-in-the-middle can therefore truncate the mac field
> from 16 bytes to 1 byte, reducing the tag check from 2⁻¹²⁸ to
> 2⁻⁸. Thanks to Calif.io in collaboration with Claude and Anthropic
> Research for the report. Fixed in PR 10102.
>
>     [High] CVE-2026-5501
>     wolfSSL_X509_verify_cert() in the OpenSSL compatibility layer
> accepts a certificate chain in which the leaf's signature is not
> checked, if the attacker supplies an untrusted intermediate with Basic
> Constraints CA:FALSE that is legitimately signed by a trusted root. An
> attacker who obtains any leaf certificate from a trusted CA (e.g. a free
> DV cert from Let's Encrypt) can forge a certificate for any subject name
> with any public key and arbitrary signature bytes, and the function
> returns WOLFSSL_SUCCESS / X509_V_OK. The native wolfSSL TLS handshake
> path (ProcessPeerCerts) is not susceptible and the issue is limited to
> applications using the OpenSSL compatibility API directly. Thanks to
> Calif.io in collaboration with Claude and Anthropic Research for the
> report. Fixed in PR 10102.
>
>     [High] CVE-2026-5503
>     In TLSX_EchChangeSNI, the ctx->extensions branch set extensions
> unconditionally even when TLSX_Find returned NULL. This caused
> TLSX_UseSNI to attach the attacker-controlled publicName to the shared
> WOLFSSL_CTX when no inner SNI was configured. TLSX_EchRestoreSNI then
> failed to clean it up because its removal was gated on serverNameX !=
> NULL. The inner ClientHello was sized before the pollution but written
> after it, causing TLSX_SNI_Write to memcpy 255 bytes past the allocation
> boundary. Thanks to Calif.io in collaboration with Claude and Anthropic
> Research for the report. Fixed in PR 10102.
>
>     [Med] CVE-2026-5392
>     Heap out-of-bounds read in PKCS7 parsing. A crafted PKCS7 message
> can trigger an OOB read on the heap. The missing bounds check is in the
> indefinite-length end-of-content verification loop in
> PKCS7_VerifySignedData(). This only affects builds with PKCS7 support
> enabled. Thanks to J Laratro (d0sf3t) for the report. Fixed in PR 10039.
>
>     [Med] CVE-2026-5446
>     ARIA-GCM nonce reuse in TLS 1.2 record encryption. ARIA cipher
> support requires a proprietary Korean library (MagicCrypto) and
> --enable-aria, limiting real-world exposure. Thanks to Calif.io in
> collaboration with Claude and Anthropic Research for the report. Fixed
> in PR 10111.
>
>     [Med] CVE-2026-5460
>     When a malicious TLS 1.3 server sends a ServerHello with a truncated
> PQC hybrid KeyShare (e.g., P256_ML_KEM_512 with 10 bytes instead of the
> required 768+), the error cleanup path double-frees the KyberKey. Thanks
> to Calvin Young (eWalker Consulting Inc.) and Enoch Chow (Isomorph
> Cyber). Fixed in PR 10092.
>
>     [Med] CVE-2026-5504
>     A padding oracle exists in wolfSSL's PKCS7 CBC decryption that could
> allow an attacker to recover plaintext through repeated decryption
> queries with modified ciphertext. In previous versions of wolfSSL the
> interior padding bytes are not validated. Thanks to Sunwoo Lee, Woohyun
> Choi, and Seunghyun Yoon of Korea Institute of Energy Technology
> (KENTECH) for the report. Fixed in PR 10088.
>
>     [Med] CVE-2026-5507
>     When restoring a session from cache, a pointer from the serialized
> session data is used in a free operation without validation. An attacker
> who can poison the session cache could trigger an arbitrary free.
> Exploitation requires the ability to inject a crafted session into the
> cache and for the application to call specific session restore APIs.
> Thanks to Sunwoo Lee, Woohyun Choi, and Seunghyun Yoon of Korea
> Institute of Energy Technology (KENTECH) for the report. Fixed in PR
> 10088.
>
>     [Low] CVE-2026-5187
>     Heap out-of-bounds write in DecodeObjectId() caused by an off-by-one
> bounds check combined with a sizeof mismatch. A crafted ASN.1 object
> identifier can trigger a small heap OOB write. Thanks to Yuteng for the
> report. Fixed in PR 10025.
>
>     [Low] CVE-2026-5188
>     An integer underflow issue exists in wolfSSL when parsing the
> Subject Alternative Name (SAN) extension of X.509 certificates. A
> malformed certificate can specify an entry length larger than the
> enclosing sequence, causing the internal length counter to wrap during
> parsing. This results in incorrect handling of certificate data. The
> issue is limited to configurations using the original ASN.1 parsing
> implementation. The original ASN.1 parsing implementation is off by
> default. Thanks to Muhammad Arya Arjuna Habibullah for the report. Fixed
> in PR 10024.
>
>     [Low] CVE-2026-5448
>     X.509 date buffer overflow in wolfSSL_X509_notAfter /
> wolfSSL_X509_notBefore. A buffer overflow may occur when parsing date
> fields from a crafted X.509 certificate via the compatibility layer API.
> This is only triggered when calling these two APIs directly from an
> application, and does not affect TLS or certificate verify operations in
> wolfSSL. Thanks to Sunwoo Lee and Seunghyun Yoon, Korea Institute of
> Energy Technology (KENTECH) for the report. Fixed in PR 10071.
>
>     [Low] CVE-2026-5772
>     A 1-byte stack buffer over-read exists in the MatchDomainName
> function in src/internal.c when processing wildcard patterns with the
> LEFT_MOST_WILDCARD_ONLY flag active. When a wildcard '*' exhausts the
> entire hostname string (strLen reaches 0), the function proceeds to
> compare remaining pattern characters against the now-exhausted buffer
> without a bounds check, causing an out-of-bounds read. Thanks to Zou
> Dikai for the report. Fixed in PR 10119.
>
>     [Low] CVE-2026-5778
>     An integer underflow exists in the ChaCha20-Poly1305 decryption path
> where a malformed TLS 1.2 record with a payload shorter than the AEAD
> MAC size causes the message length calculation to underflow, resulting
> in an out-of-bounds read. This only affects sniffer builds. Thanks to
> Zou Dikai for the report. Fixed in PR 10125.
>
> Experimental Build Vulnerability
>
>     [Med] CVE-2026-5393
>     Dual-Algorithm CertificateVerify out-of-bounds read. When processing
> a dual-algorithm CertificateVerify message, an out-of-bounds read can
> occur on crafted input. This can only occur when --enable-experimental
> and --enable-dual-alg-certs is used when building wolfSSL. Thanks to
> Sunwoo Lee, Woohyun Choi, and Seunghyun Yoon (Korea Institute of Energy
> Technology, KENTECH) for testing the fix. Fixed in PR 10079.

Also listed are many issues/fixes that are not labeled vulnerabilities,
including the one just brought in here by Abhinav Agarwal (thanks!)

https://www.openwall.com/lists/oss-security/2026/04/14/5

> Zeroize sensitive memory buffers in the ML-DSA (Dilithium)
> implementation to prevent leakage of cryptographic material. by
> @Frauschi (PR 10100)

> Ensured that the heap buffer used (among others) to store sensitive data
> during ML-DSA signing is zeroized before freeing the memory. Thanks to
> Abhinav Agarwal (@abhinavagarwal07) for the report. (PR 10113)

but really, there are many other issues/changes in there that may also
have security relevance.

Alexander