CVE-2026-69247

What it actually does

The flaw is a cryptographic oracle in Python cryptography package versions 44.0.0 through before 50.0.0 when applications use pkcs7_decrypt_der, pkcs7_decrypt_pem, or pkcs7_decrypt_smime to decrypt attacker-supplied PKCS#7/S/MIME EnvelopedData. The affected code can expose distinguishable failure modes and timing differences during RSA PKCS#1 v1.5 decryption of the RecipientInfo encryptedKey, including whether RSA padding was invalid, whether the recovered key had an invalid AES key length, whether AES-CBC/PKCS#7 unpadding failed, or whether decryption succeeded. In applications that reflect these differences and allow high-volume adaptive queries, an attacker can build a Bleichenbacher-style oracle to recover the content-encryption key and decrypt protected message content. The invalid-RSA-padding path is specifically reachable where the linked crypto backend lacks implicit rejection, including OpenSSL 3.0, OpenSSL 3.1, LibreSSL, and BoringSSL.

Why it matters to the business

Organizations running affected cryptography versions in services that automatically decrypt untrusted S/MIME or PKCS#7 data may expose confidential encrypted message contents without requiring authentication. The highest-risk deployments are mail gateways, S/MIME processing services, mail filters, document intake systems, or automated decryption APIs that return different errors or response times to remote senders. The CVSS confidentiality impact is high, but exploitation requires a specialized adaptive attack, high request volume, a matching recipient certificate, and observable responses, so broad opportunistic exploitation is less likely than targeted attacks against exposed decryption workflows. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at publication time, but the affected library is widely used in Python ecosystems, making inventory and upgrade important wherever PKCS#7 decryption is enabled.

How an attack unfolds

An attacker first identifies a service that accepts attacker-controlled PKCS#7 or S/MIME EnvelopedData and attempts to decrypt it using a victim certificate. The attacker crafts many modified RecipientInfo encryptedKey values and submits them to the service. If the service exposes different HTTP status codes, mail bounce messages, API errors, logs visible to the sender, or measurable timing differences for RSA padding failure, invalid AES key length, CBC padding failure, and successful decryption, those responses become an oracle. By adaptively choosing new ciphertexts based on prior responses, the attacker performs a Bleichenbacher-style attack against RSA PKCS#1 v1.5 encryption of the content-encryption key. Once the content-encryption key is recovered, the attacker can decrypt the S/MIME or PKCS#7 message body protected under that key. Practical exploitation is most plausible against automated S/MIME gateways or mail security filters that process large volumes of attacker-supplied messages and reveal decryption outcomes consistently.

How to fix it

Upgrade the Python cryptography package to version 50.0.0 or later everywhere PKCS#7 decryption may be used. Rebuild and redeploy applications, containers, virtual environments, serverless packages, and vendor bundles that vendor or pin cryptography versions 44.0.0 through 49.x. If immediate upgrade is not possible, disable automatic decryption of untrusted PKCS#7/S/MIME EnvelopedData, restrict decryption endpoints to trusted authenticated sources, rate-limit decryption attempts, normalize all decryption failures to one generic response, and ensure response timing does not reveal which decryption stage failed. Avoid exposing low-level cryptographic exception details to callers, mail senders, or API clients. For S/MIME gateways and mail filters, consider quarantining malformed EnvelopedData instead of returning detailed delivery or processing errors.

How to confirm the fix worked

Confirm package inventory shows cryptography version 50.0.0 or later in every relevant Python runtime, container image, virtual environment, and dependency lock file. Check with commands such as python -m pip show cryptography, pip freeze, pipdeptree, poetry show cryptography, or equivalent SBOM tooling. Review code for use of pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime, especially in message-processing, mail-filtering, document-ingestion, or API workflows. Exercise negative test cases using malformed PKCS#7/S/MIME EnvelopedData and verify callers receive the same generic failure response regardless of RSA padding, key length, AES-CBC, or unpadding failure. Measure response timing under repeated malformed inputs to ensure timing differences are not externally distinguishable. Validate that logs retain sufficient internal diagnostic value but do not expose detailed cryptographic failure causes to untrusted clients.

Typical attack path

1. Identify an externally reachable application, gateway, or mail-processing workflow that decrypts PKCS#7 or S/MIME EnvelopedData.
2. Confirm the service uses an affected Python cryptography version from 44.0.0 up to but not including 50.0.0 and invokes pkcs7_decrypt_der, pkcs7_decrypt_pem, or pkcs7_decrypt_smime, or infer this behavior through response patterns.
3. Obtain or target EnvelopedData associated with the victim recipient certificate.
4. Generate many modified encryptedKey values in RecipientInfo structures.
5. Submit crafted messages repeatedly and observe response differences such as error text, status codes, bounce behavior, or response timing.
6. Use the distinguishable outcomes as a Bleichenbacher oracle to narrow the RSA PKCS#1 v1.5 plaintext space.
7. Recover the content-encryption key.
8. Decrypt the protected S/MIME or PKCS#7 content offline.

How to detect it

There is no universal file, process, or network indicator proving exploitation because the attack consists of many malformed PKCS#7/S/MIME decryption attempts and observation of application behavior. Hunt in mail gateway logs, MTA logs, API gateway logs, application logs, WAF logs, reverse proxy logs, and cryptographic exception telemetry for high-volume submissions of S/MIME or PKCS#7 EnvelopedData followed by repeated decryption errors. Look for many similar messages from the same sender, IP address, ASN, authenticated principal, or relay with small variations in encrypted payloads. Useful signals include repeated application/pkcs7-mime or application/x-pkcs7-mime messages, smime-type=enveloped-data, PEM PKCS7 blocks, bursts of malformed RecipientInfo/encryptedKey parsing, and sequences of differing decryption failures such as RSA decrypt failure, invalid AES key size, bad CBC padding, or PKCS#7 unpadding errors. For HTTP services, correlate repeated POSTs of DER/PEM PKCS#7 content with varying response sizes, status codes, error bodies, or latency. For mail systems, review bounces, quarantine events, and filtering outcomes that distinguish malformed encrypted messages. If exploitation is suspected, preserve the submitted encrypted objects, response metadata, timing data, and application logs; the payloads may not contain a conventional malware artifact but can show adaptive oracle probing patterns.

• pkcs7_decrypt_der
• pkcs7_decrypt_pem
• pkcs7_decrypt_smime
• application/pkcs7-mime
• application/x-pkcs7-mime
• smime-type=enveloped-data
• -----BEGIN PKCS7-----
• -----END PKCS7-----
• RecipientInfo
• encryptedKey
• Invalid key size
• Invalid padding bytes
• Decryption failed

What your security team should do

• Prioritize inventory of Python applications and appliances that process S/MIME, PKCS#7, CMS, or EnvelopedData, because only systems that decrypt attacker-supplied encrypted content are realistically exploitable.
• Upgrade cryptography to 50.0.0 or later and redeploy all affected application artifacts, including containers, virtual environments, and embedded vendor packages.
• Search source code and dependency manifests for pkcs7_decrypt_der, pkcs7_decrypt_pem, pkcs7_decrypt_smime, and cryptography versions 44.0.0 through 49.x.
• For internet-facing mail gateways, S/MIME processors, and decryption APIs, add rate limits and generic error handling even after patching to reduce exposure to oracle-style attacks.
• Review logs for high-volume malformed S/MIME or PKCS#7 submissions, repeated decryption failures, and timing-probing behavior from the same source over short intervals.
• Ensure application responses, bounces, and API errors do not disclose cryptographic exception details to unauthenticated or untrusted users.
• If sensitive encrypted messages may have been targeted, assess whether message confidentiality could have been exposed and consider rotating affected certificates or keys where operationally appropriate.