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, they should be fixed in 5.9.2, please verify again the referenced pull request in the security-tracker. CVE-2026-6091[0]: | Partial-chain certificate verification may accept chains that | terminate at a peer-supplied, untrusted intermediate certificate | rather than a trusted anchor. An attacker could present a chain that | ends at an intermediate they control and have it accepted as valid. | This affects the OpenSSL compatibility certificate-path-building | path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the | X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled. CVE-2026-6094[1]: | Heap buffer overread in wc_PKCS7_DecodeEnvelopedData when parsing | crafted PKCS7 EnvelopedData. This could theoretically be triggered | by attacker-supplied data delivered via S/MIME or CMS. CVE-2026-6291[2]: | Bleichenbacher padding oracle in PKCS#7 KTRI decryption. When | decrypting PKCS#7 EnvelopedData using RSA PKCS#1 v1.5 key transport, | wolfSSL returned distinguishable error codes depending on whether | RSA padding validation failed versus whether the decrypted content | was malformed. An attacker able to submit crafted EnvelopedData | messages and observe error responses could use this as a padding | oracle to incrementally recover the encrypted Content Encryption Key | (CEK). The fix generates a deterministic pseudo-random fake CEK on | padding failure (via HMAC-SHA256) and proceeds with decryption | identically, using constant-time operations throughout, so that all | failure paths produce the same error regardless of padding validity. CVE-2026-55961[3]: | wolfSSL_PKCS7_verify() returning success for a degenerate (certs- | only) PKCS#7 object that contains no signer. Such an object has | empty signerInfos, so the underlying signed-data verification | succeeds without authenticating any content. The compatibility-layer | verify path now rejects the object when no signer signature has | actually been verified, so a PKCS#7 carrying no valid signature is | no longer reported as verified. This is enforced regardless of the | PKCS7_NOVERIFY flag, which only suppresses signer certificate chain | validation and was never intended to waive the requirement that a | signature exist. Only affects OpenSSL compatibility builds that call | the PKCS7_verify() compatibility API on potentially degenerate | PKCS#7 bundles. CVE-2026-55967[4]: | AES-GCM encryption/decryption with extremely large cumulative single | message sizes (>64 GiB) were not properly rejected by the streaming | APIs, allowing counter wrap, keystream reuse, and consequent | plaintext recovery. 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-6091 https://www.cve.org/CVERecord?id=CVE-2026-6091 [1] https://security-tracker.debian.org/tracker/CVE-2026-6094 https://www.cve.org/CVERecord?id=CVE-2026-6094 [2] https://security-tracker.debian.org/tracker/CVE-2026-6291 https://www.cve.org/CVERecord?id=CVE-2026-6291 [3] https://security-tracker.debian.org/tracker/CVE-2026-55961 https://www.cve.org/CVERecord?id=CVE-2026-55961 [4] https://security-tracker.debian.org/tracker/CVE-2026-55967 https://www.cve.org/CVERecord?id=CVE-2026-55967 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
