Update dependency cryptography to v50 [SECURITY] #217
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "renovate/pypi-cryptography-vulnerability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
49.0.0→50.0.0cryptography: PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing
CVE-2026-69247 / GHSA-g6cj-pr64-35w5 / PYSEC-2026-3552
More information
Details
Summary
pkcs7_decrypt_der,pkcs7_decrypt_pem, andpkcs7_decrypt_smimereported theoutcome of decrypting a
RecipientInfo'sencryptedKeyin severaldistinguishable 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
EnvelopedDataand reflects theoutcome 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 AEScipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed
differently, with no RFC 3218 mitigation:
Decryption failedInvalid key size (N) for AES., disclosingNInvalid padding bytes.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
EnvelopedDatamatching 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 resolved before the
private key is used, so the expected key length is known in advance. If the RSA
decryption fails or recovers a key of the wrong length, a random key of the
expected length is substituted and decryption continues down an identical path.
All failures now report identically and perform the same work.
Not addressed by this fix
EnvelopedDatadoes not authenticate its content. Tampering withencryptedContentalone yields a CBC padding oracle that recovers plaintext atroughly 256 queries per byte, without recovering any key, on every backend. This
is a property of PKCS#7 rather than of this implementation, cannot be fixed in
the library, and is now documented.
Credit
Reported by @X1AOxiang.
Severity
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
cryptography: PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing
CVE-2026-69247 / GHSA-g6cj-pr64-35w5 / PYSEC-2026-3552
More information
Details
Summary
pkcs7_decrypt_der,pkcs7_decrypt_pem, andpkcs7_decrypt_smimereported theoutcome of decrypting a
RecipientInfo'sencryptedKeyin severaldistinguishable 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
EnvelopedDataand reflects theoutcome 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 AEScipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed
differently, with no RFC 3218 mitigation:
Decryption failedInvalid key size (N) for AES., disclosingNInvalid padding bytes.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
EnvelopedDatamatching 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 resolved before the
private key is used, so the expected key length is known in advance. If the RSA
decryption fails or recovers a key of the wrong length, a random key of the
expected length is substituted and decryption continues down an identical path.
All failures now report identically and perform the same work.
Not addressed by this fix
EnvelopedDatadoes not authenticate its content. Tampering withencryptedContentalone yields a CBC padding oracle that recovers plaintext atroughly 256 queries per byte, without recovering any key, on every backend. This
is a property of PKCS#7 rather than of this implementation, cannot be fixed in
the library, and is now documented.
Credit
Reported by @X1AOxiang.
Severity
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).
Release Notes
pyca/cryptography (cryptography)
v50.0.0Compare Source
Configuration
📅 Schedule: (in timezone Europe/Amsterdam)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.
Superseded by #218, which bundles this round of bumps into one branch. Every change from this PR is included there unchanged.
Pull request closed