https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 23:28:51 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11010 bdu:2026-11010 https://cve.radiocsirt.org/vuln/bdu:2026-11010 https://cve.radiocsirt.org/vuln/brew-ansible@10-cve-2026-69247 <p><strong>Affected:</strong> Homebrew: ansible@10</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> <p><strong>Affected:</strong> Homebrew: ansible@10</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> https://cve.radiocsirt.org/vuln/brew-ansible@10-cve-2026-69247 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094 certfr-2026-avi-1094 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094 https://cve.radiocsirt.org/vuln/cleanstart-2026-cf86587 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Package litellm-database version 1.94.3-r0 fixes 3 vulnerabilities: CVE-2026-69247, CVE-2026-69248, CVE-2026-69249</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Package litellm-database version 1.94.3-r0 fixes 3 vulnerabilities: CVE-2026-69247, CVE-2026-69248, CVE-2026-69249</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-cf86587 https://cve.radiocsirt.org/vuln/euvd-2026-344071 EUVD-2026-344071 https://cve.radiocsirt.org/vuln/euvd-2026-344071 https://cve.radiocsirt.org/vuln/fkie_cve-2026-69247 <p>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&#39;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.</p> <p>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&#39;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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-69247 https://cve.radiocsirt.org/vuln/ghsa-g6cj-pr64-35w5 <p><strong>Affected:</strong> PyPI: cryptography</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> <p><strong>Affected:</strong> PyPI: cryptography</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> https://cve.radiocsirt.org/vuln/ghsa-g6cj-pr64-35w5 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11468-1 <p>python313-cryptography-50.0.0-1.1 on GA media</p> <p>python313-cryptography-50.0.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11468-1 https://cve.radiocsirt.org/vuln/pysec-2026-3552 <p><strong>Affected:</strong> PyPI: cryptography</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> <p><strong>Affected:</strong> PyPI: cryptography</p> <p>### Summary</p> <p>`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the outcome of decrypting a `RecipientInfo`&#39;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.</p> <p>Introduced in 44.0.0. Fixed in 50.0.0.</p> <p>### Details</p> <p>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:</p> <p>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</p> <p>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.</p> <p>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.</p> <p>### Fix</p> <p>Per RFC 3218, the content-encryption algorithm is now r…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3552 https://cve.radiocsirt.org/vuln/rhsa-2026:55543 <p>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…</p> <p>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…</p> https://cve.radiocsirt.org/vuln/rhsa-2026:55543 https://cve.radiocsirt.org/vuln/suse-su-2026:23404-1 <p>Security update for python-cryptography</p> <p>Security update for python-cryptography</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23404-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-69247 <p><strong>Affected:</strong> Ubuntu:26.04:LTS: python-cryptography</p> <p>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&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:26.04:LTS: python-cryptography</p> <p>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&#39;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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-69247