Source: wolfssl Version: 5.9.1-0.1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
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
