CVE-2026-69247: 
Mitmproxy vulnerability analysis and mitigation

CVE-2026-69247 is a Bleichenbacher oracle vulnerability in the Python cryptography package (pyca/cryptography) affecting versions 44.0.0 through 49.x. The functions pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime exposed distinguishable error messages and timing differences when decrypting a RecipientInfo's encryptedKey, allowing an attacker to use the service as a Bleichenbacher oracle against the content-encryption key. The vulnerability was introduced in version 44.0.0 and fixed in 50.0.0. It was reported by @X1AOxiang, published on July 31, 2026, and carries a CVSS v4.0 base score of 8.2 (High) (Github Advisory).

The root cause is a combination of CWE-208 (Observable Timing Discrepancy) and CWE-209 (Generation of Error Message Containing Sensitive Information). The PKCS#7 decryption pipeline proceeded as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build AES cipher from result → AES-CBC decrypt → PKCS#7 unpad. Each stage failed with a distinct, distinguishable error: invalid RSA padding produced "Decryption failed", valid padding with a wrong-length key produced "Invalid key size (N) for AES." (leaking the exact recovered length N), a correct-length but wrong key produced "Invalid padding bytes.", and the real key succeeded. The wrong-length case also returned early before the AES-CBC pass, making the distinction observable by timing. Case 1 (invalid RSA padding) is only reachable when the underlying library lacks implicit rejection — specifically OpenSSL 3.0/3.1, LibreSSL, and BoringSSL; OpenSSL 3.2+ returns a synthetic pseudorandom plaintext, closing that channel. The fix, per RFC 3218, resolves the content-encryption algorithm before RSA decryption, substitutes a random key of the expected length on any failure, and continues down an identical code path so all outcomes are indistinguishable (Github Advisory, Fix PR, Fix Commit).

Successful exploitation allows an attacker to use a vulnerable service as a Bleichenbacher oracle to recover the AES content-encryption key used to protect PKCS#7 EnvelopedData messages, resulting in a high confidentiality impact. There is no integrity or availability impact. Exploitation is limited to scenarios where a service automatically decrypts attacker-supplied EnvelopedData matching the victim's certificate and returns distinguishable outcomes at high volume — such as an S/MIME gateway or mail filter. Additionally, the advisory notes a residual, unfixed CBC padding oracle inherent to PKCS#7 itself: tampering with encryptedContent alone can recover plaintext at approximately 256 queries per byte on any backend, regardless of this fix (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for this vulnerability. The EPSS score is approximately 0.175% (7th percentile), indicating a low near-term exploitation probability. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable. Exploitation requires high attack complexity and specific preconditions: the attacker must be able to submit crafted EnvelopedData to a service that auto-decrypts it and returns adaptive responses at high volume. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Identify a vulnerable service: Locate a service that automatically decrypts PKCS#7 EnvelopedData messages (e.g., an S/MIME gateway, mail filter, or API endpoint) using pyca/cryptography versions 44.0.0–49.x, backed by OpenSSL 3.0/3.1, LibreSSL, or BoringSSL.
2. Obtain the victim's certificate: Retrieve the recipient's X.509 certificate (e.g., from a public directory, email header, or LDAP) to construct valid EnvelopedData structures targeting that recipient.
3. Craft malicious EnvelopedData: Build EnvelopedData structures with manipulated encryptedKey values — for example, all-zero bytes (invalid PKCS#1 v1.5 padding), or RSA-encrypted payloads of varying lengths (e.g., 15, 17, 32 bytes) to probe the oracle's error responses.
4. Submit queries and observe responses: Send crafted messages to the service at high volume and observe the distinguishable error responses or timing differences: "Decryption failed" (invalid padding), "Invalid key size (N) for AES." (wrong length, leaking N), or "Invalid padding bytes." (correct length, wrong key).
5. Execute Bleichenbacher attack: Use the oracle responses to iteratively narrow down the RSA plaintext (the content-encryption key) using the classical Bleichenbacher '98 adaptive chosen-ciphertext attack methodology, requiring thousands to millions of queries.
6. Recover content-encryption key: Once the AES key is recovered, decrypt the intercepted EnvelopedData ciphertext to obtain the plaintext content (Github Advisory, Fix PR).

• Network: Unusually high volume of PKCS#7/S/MIME decryption requests to an S/MIME gateway or mail processing service from a single source IP or small IP range; requests containing structurally valid but semantically manipulated EnvelopedData (e.g., encryptedKey fields of unusual or varying lengths).
• Logs: Application logs showing repeated decryption errors such as "Decryption failed", "Invalid key size for AES", or "Invalid padding bytes" in rapid succession from the same sender or message source; anomalous spikes in PKCS#7 decryption failure rates.
• Application Behavior: Automated decryption service processing a large number of messages addressed to the same recipient certificate in a short time window, particularly messages that fail decryption; messages with encryptedKey values that are all-zero or otherwise structurally abnormal.

The primary remediation is to upgrade the cryptography package to version 50.0.0 or later, which implements the RFC 3218 countermeasure: substituting a random key of the expected length on any RSA decryption failure and continuing down an identical code path so all outcomes are indistinguishable. No configuration-based workaround is available for the library-level flaw. As an architectural mitigation, services should avoid automatically decrypting attacker-supplied EnvelopedData and reflecting the outcome; if decryption of untrusted messages is required, ensure responses do not distinguish between decryption failure modes. Note that the residual CBC padding oracle (inherent to PKCS#7) is not addressed by this fix and is now documented in the library (Github Advisory, Fix Commit).

The fix was authored by alex (a core pyca maintainer) and merged by reaperhulk on July 31, 2026, with credit to researcher @X1AOxiang for responsible disclosure. A Reddit post in r/vibecoding noted the issue for cryptography users. Multiple downstream projects — including KServe, Red Hat notebooks, NixOS, and others — promptly issued dependency bumps to address the vulnerability, reflecting broad ecosystem awareness. The Yocto Project security mailing list also flagged the issue for embedded Linux users (Github Advisory, Fix PR).