Hi,

The following vulnerabilities were published for wolfssl.

CVE-2026-55958[0]:
| Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer.
| In tsip_StoreMessage() the capacity check guarding the fixed message
| bag (MSGBAG_SIZE) sets an error code but fails to return, so
| execution falls through to an XMEMCPY that writes past the end of
| the buffer once the accumulated TLS 1.3 handshake transcript exceeds
| MSGBAG_SIZE (8 KB), corrupting adjacent heap state and potentially
| causing a remote denial of service crash. The bag is sized to hold a
| normal handshake, so this is reached only by an unusually large but
| valid certificate chain, or by a malicious or man-in-the-middle
| server sending an oversized handshake message to a client that does
| not strictly verify the chain. This only affects builds using the
| Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) as a TLS 1.3 client
| on Renesas MCUs with TSIP hardware enabled, and is rated High within
| those builds. All other configurations are unaffected.


CVE-2026-55960[1]:
| Un-negotiated Raw Public Key (RFC 7250) accepted in place of an
| X.509 certificate, bypassing chain validation. A raw public key has
| no chain, so ParseCertRelative() accepts it without performing any
| trust verification; it must therefore only be accepted when RPK was
| actually negotiated for that peer. The check now defaults the
| expected type to X.509 (per RFC 7250/8446) when no type was
| negotiated, comparing against the received server certificate type
| on the client and the selected client certificate type on the
| server, and rejects any mismatch, including an un-negotiated raw
| public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with
| Raw Public Key support (HAVE_RPK) enabled - disabled by default in a
| standalone build, but included in --enable-all.


CVE-2026-55962[2]:
| TLS 1.3 post-handshake authentication (PHA) issue where a server
| could accept a client's Finished message without the client having
| sent a Certificate and CertificateVerify. The post-handshake-auth
| exemption that allows an empty/absent peer certificate was only
| intended for the initial handshake, but it was also being applied
| while a post-handshake CertificateRequest was still outstanding. The
| check is now scoped to the initial handshake only: on the server,
| once a post-handshake CertificateRequest has been sent (certReqCtx
| is set), a peer certificate and a valid CertificateVerify are
| required again before the Finished is accepted, with empty-
| certificate handling following the configured verify mode
| (FAIL_IF_NO_PEER_CERT) just as during first-handshake client
| authentication. Only affects TLS 1.3 servers built with post-
| handshake authentication support (WOLFSSL_POST_HANDSHAKE_AUTH /
| --enable-postauth, included in --enable-all) that enable
| WOLFSSL_VERIFY_POST_HANDSHAKE and request a client certificate after
| the handshake via wolfSSL_request_certificate(). Clients, and
| servers that do not use post-handshake authentication, are
| unaffected.


CVE-2026-55964[3]:
| Chain intermediate CA:TRUE without keyCertSign accepted as a signing
| CA. Intermediate CA certificates are required to have the
| keyCertSign key usage when a Key Usage extension is present, but
| chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building
| a certificate path were previously exempted from this check, so an
| intermediate asserting CA:TRUE but lacking keyCertSign was accepted
| as a signing CA. The check now applies to chain-supplied temporary
| CAs as well; only operator-loaded root certificates
| (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280
| an absent Key Usage extension implies all usages, so the requirement
| is enforced only when the extension is actually present
| (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-
| path-building path (X509_verify_cert / X509_STORE,
| OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are
| added as temporary CAs; native (non-OpenSSL-compat) certificate
| verification does not create temporary CAs and is unaffected. Within
| those builds, the check applies unless ALLOW_INVALID_CERTSIGN is
| defined.


CVE-2026-6092[4]:
| When HAVE_ENCRYPT_THEN_MAC is configured, the implementation could
| fall back to MAC-then-Encrypt rather than enforcing Encrypt-then-
| MAC.


CVE-2026-6325[5]:
| Out-of-bounds write in SetSuitesHashSigAlgo when processing an
| oversized signature algorithms list, allowing a write past the
| bounds of the destination buffer.


CVE-2026-6329[6]:
| PKCS#12 MAC verification uses an attacker-controlled comparison
| length, weakening the integrity check on the MAC and allowing a
| mismatched MAC to be accepted. The PKCS#12 verify path compared the
| locally computed HMAC against the MAC parsed from the PKCS#12
| structure using a length taken directly from the attacker-supplied
| input, without first verifying that it equals the length of the
| digest actually produced by the configured algorithm. A truncated or
| zero-length stored MAC could therefore be accepted, defeating the
| integrity protection of the MAC.


CVE-2026-6330[7]:
| The ML-KEM ARM64 NEON ciphertext comparison only compares half of
| the input, breaking the Fujisaki-Okamoto transform's implicit
| rejection and weakening IND-CCA2 security on that code path. The
| constant-time comparison effectively ignored part of the re-
| encrypted ciphertext, so a decapsulating party could fail to detect
| a manipulated ciphertext and proceed without the standard's required
| implicit rejection.


CVE-2026-6331[8]:
| HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-
| length tag could be accepted as valid during HMAC verification. In
| the OpenSSL-compatibility HMAC verify path the supplied signature
| length was only checked as not exceeding the MAC length, so a zero-
| length or otherwise truncated tag could pass verification. The fix
| requires the supplied tag length to exactly equal the MAC length and
| rejects a zero-length MAC, so a forged short or empty tag is no
| longer accepted.


CVE-2026-6412[9]:
| Certificate policy and RFC 8446 compliance concerns regarding the
| continued acceptance of SHA-1/MD5 in certificate processing.


CVE-2026-6450[10]:
| A CRL critical extension bypass exists in ParseCRL_Extensions where
| critical extensions are not properly enforced, allowing a crafted
| CRL with an unhandled critical extension to be accepted. This only
| affects builds with CRL support enabled and where a crafted CRL had
| a trusted signature when parsed.


CVE-2026-6678[11]:
| Integer underflow in wc_PKCS7_DecryptOri when handling crafted Other
| Recipient Info, leading to incorrect length handling during
| decryption.


CVE-2026-6731[12]:
| X.509 name constraint bypass via the Subject Common Name when
| treated as a DNS-type name. A certificate whose Subject CN violates
| an issuing CA's DNS name constraints could be accepted.


CVE-2026-7511[13]:
| PKCS7_verify signer confusion allows forged signatures, where the
| signer associated with a signature is not correctly bound,
| permitting a forged signature to be accepted.


CVE-2026-7531[14]:
| 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-7532[15]:
| iPAddress name constraints bypass when WOLFSSL_IP_ALT_NAME is not
| defined. IP address name constraints are not enforced in that
| configuration, allowing a certificate to bypass an issuing CA's IP
| address constraints.


CVE-2026-8720[16]:
| wc_Blake2bHmacFinal and wc_Blake2sHmacFinal discard the message when
| the key length exceeds the block size, producing a MAC that is
| independent of the input. When the supplied key is longer than the
| BLAKE2 block size the key-hashing branch reinitialized the running
| hash state, discarding the accumulated message data, so the
| resulting MAC depended only on the key and not on the message being
| authenticated. This bug is specific to the HMAC-BLAKE2 APIs that
| were added in wolfSSL version 5.9.0.


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-55958
https://www.cve.org/CVERecord?id=CVE-2026-55958
[1] https://security-tracker.debian.org/tracker/CVE-2026-55960
https://www.cve.org/CVERecord?id=CVE-2026-55960
[2] https://security-tracker.debian.org/tracker/CVE-2026-55962
https://www.cve.org/CVERecord?id=CVE-2026-55962
[3] https://security-tracker.debian.org/tracker/CVE-2026-55964
https://www.cve.org/CVERecord?id=CVE-2026-55964
[4] https://security-tracker.debian.org/tracker/CVE-2026-6092
https://www.cve.org/CVERecord?id=CVE-2026-6092
[5] https://security-tracker.debian.org/tracker/CVE-2026-6325
https://www.cve.org/CVERecord?id=CVE-2026-6325
[6] https://security-tracker.debian.org/tracker/CVE-2026-6329
https://www.cve.org/CVERecord?id=CVE-2026-6329
[7] https://security-tracker.debian.org/tracker/CVE-2026-6330
https://www.cve.org/CVERecord?id=CVE-2026-6330
[8] https://security-tracker.debian.org/tracker/CVE-2026-6331
https://www.cve.org/CVERecord?id=CVE-2026-6331
[9] https://security-tracker.debian.org/tracker/CVE-2026-6412
https://www.cve.org/CVERecord?id=CVE-2026-6412
[10] https://security-tracker.debian.org/tracker/CVE-2026-6450
https://www.cve.org/CVERecord?id=CVE-2026-6450
[11] https://security-tracker.debian.org/tracker/CVE-2026-6678
https://www.cve.org/CVERecord?id=CVE-2026-6678
[12] https://security-tracker.debian.org/tracker/CVE-2026-6731
https://www.cve.org/CVERecord?id=CVE-2026-6731
[13] https://security-tracker.debian.org/tracker/CVE-2026-7511
https://www.cve.org/CVERecord?id=CVE-2026-7511
[14] https://security-tracker.debian.org/tracker/CVE-2026-7531
https://www.cve.org/CVERecord?id=CVE-2026-7531
[15] https://security-tracker.debian.org/tracker/CVE-2026-7532
https://www.cve.org/CVERecord?id=CVE-2026-7532
[16] https://security-tracker.debian.org/tracker/CVE-2026-8720
https://www.cve.org/CVERecord?id=CVE-2026-8720

Regards,
Salvatore