Affected: Homebrew: ansible@10

### Summary

`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`'s `encryptedKey` in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied `EnvelopedData` and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key.

Introduced in 44.0.0. Fixed in 50.0.0.

### Details

Decryption ran as: RSA PKCS#1 v1.5 decrypt of `encryptedKey` → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation:

1. invalid RSA padding → `Decryption failed` 2. valid padding, bad key length → `Invalid key size (N) for AES.`, disclosing `N` 3. correct length, wrong key → `Invalid padding bytes.` 4. the real key → plaintext

Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts.

Exploitation requires a service that auto-decrypts untrusted `EnvelopedData` matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter.

### Fix

Per RFC 3218, the content-encryption algorithm is now r…

Withdrawn by the publisher.

Affected: CleanStart: litellm-database

Package litellm-database version 1.94.3-r0 fixes 3 vulnerabilities: CVE-2026-69247, CVE-2026-69248, CVE-2026-69249

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 44.0.0 until 50.0.0, pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Decryption ran as RSA PKCS#1 v1.5 decrypt of encryptedKey, build an AES cipher from the result, then AES-CBC decrypt and PKCS#7 unpad. Invalid RSA padding, a valid padding with a bad key length, a correct length with a wrong key, and the real key each failed or succeeded differently. Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. This issue is fixed in 50.0.0.

Affected: PyPI: cryptography

### Summary

`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`'s `encryptedKey` in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied `EnvelopedData` and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key.

Introduced in 44.0.0. Fixed in 50.0.0.

### Details

Decryption ran as: RSA PKCS#1 v1.5 decrypt of `encryptedKey` → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation:

1. invalid RSA padding → `Decryption failed` 2. valid padding, bad key length → `Invalid key size (N) for AES.`, disclosing `N` 3. correct length, wrong key → `Invalid padding bytes.` 4. the real key → plaintext

Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts.

Exploitation requires a service that auto-decrypts untrusted `EnvelopedData` matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter.

### Fix

Per RFC 3218, the content-encryption algorithm is now r…

python313-cryptography-50.0.0-1.1 on GA media

Affected: PyPI: cryptography

### Summary

`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`'s `encryptedKey` in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied `EnvelopedData` and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key.

Introduced in 44.0.0. Fixed in 50.0.0.

### Details

Decryption ran as: RSA PKCS#1 v1.5 decrypt of `encryptedKey` → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation:

1. invalid RSA padding → `Decryption failed` 2. valid padding, bad key length → `Invalid key size (N) for AES.`, disclosing `N` 3. correct length, wrong key → `Invalid padding bytes.` 4. the real key → plaintext

Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts.

Exploitation requires a service that auto-decrypts untrusted `EnvelopedData` matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter.

### Fix

Per RFC 3218, the content-encryption algorithm is now r…

openssl: OpenSSL: Heap buffer overflow due to signed integer overflow in Unicode output sizing openssl: OpenSSL: Denial of Service due to heap out-of-bounds read in CMS password-based decryption openssl: OpenSSL: Heap buffer over-read in ASN.1 decoding can lead to denial of service or information disclosure. openssl: PKCS#12 Files with PBMAC1 Are Accepted with Short HMAC Keys openssl: CMS AuthEnvelopedData Processing May Accept Forged Messages openssl: Unbounded Memory Growth in the QUIC PATH_CHALLENGE Handler openssl: Double-free When Checking OCSP Stapled Response openssl: NULL pointer dereference in QUIC server initial packet handling openssl: NULL Dereference in Certificate Verification with OCSP Checking openssl: Possible NULL Dereference in Password-Based CMS Decryption openssl: NULL Pointer Dereference in CRMF EncryptedValue Decryption openssl: Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt() openssl: Trust-Anchor Substitution via cert/issuer Typo in CMP rootCaKeyUpdate openssl: FFC-DH Peer Validation Uses Attacker-Supplied q openssl: Possible Out of Bounds Read in X509_VERIFY_PARAM_set1_email() openssl: AES-OCB IV Ignored on EVP_Cipher() Path openssl: Incorrect Tag Processing for Empty Messages in AES-GCM-SIV and AES-SIV modes openssl: Heap Use-After-Free in OpenSSL PKCS7_verify() openssl: openssl-src: OpenSSL: Memory leak leads to Denial of Service in OCSP response checking python-cryptography: python-cryptography: PKCS#7 EnvelopedData…

Security update for python-cryptography

Affected: Ubuntu:26.04:LTS: python-cryptography

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 44.0.0 until 50.0.0, pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Decryption ran as RSA PKCS#1 v1.5 decrypt of encryptedKey, build an AES cipher from the result, then AES-CBC decrypt and PKCS#7 unpad. Invalid RSA padding, a valid padding with a bad key length, a correct length with a wrong key, and the real key each failed or succeeded differently. Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. This issue is fixed in 50.0.0.