CVE-2023-50782

What it actually does

This is a cryptographic side-channel weakness in the Python pyca/cryptography library affecting RSA PKCS#1 v1.5 decryption behavior. In TLS deployments that still allow static RSA key exchange cipher suites, an unauthenticated remote attacker may be able to use decryption-oracle behavior to recover plaintext from previously captured TLS sessions. The impact is confidentiality loss only: it does not directly allow code execution, authentication bypass, data modification, or service disruption.

Why it matters to the business

Systems that terminate TLS using vulnerable cryptography code and permit RSA key exchange may expose sensitive data that was assumed to be protected in transit, including credentials, session tokens, API payloads, personal data, or business communications. The risk is highest for internet-facing services that still support legacy TLS RSA cipher suites and for organizations with long-lived private keys, because previously captured traffic may become decryptable if the attack conditions are met. This is not currently listed in CISA KEV and has low EPSS, but the issue has been public for a long time, so remediation should be treated as a hygiene and confidentiality priority, especially for services handling regulated or high-value data.

How an attack unfolds

An attacker first identifies a TLS service implemented with or dependent on a vulnerable version of pyca/cryptography and confirms that the server accepts RSA key exchange cipher suites rather than only forward-secret ECDHE/DHE suites. The attacker captures encrypted TLS traffic of interest, either passively on a network path or from previously collected packet captures. The attacker then interacts with the target TLS endpoint many times using crafted RSA-encrypted premaster secrets or related handshake inputs and observes subtle success, failure, timing, or error-response differences produced by vulnerable RSA decryption handling. By using those responses as an oracle, the attacker iteratively narrows the possible plaintext until the premaster secret for a captured session can be recovered. Once recovered, the attacker derives the TLS session keys and decrypts the captured application data. The attack is most practical where legacy RSA key exchange is enabled, network observation is available, and the attacker can generate many TLS handshakes without being blocked or rate-limited.

How to fix it

Upgrade pyca/cryptography to a fixed build. For Git-based deployments, ensure the dependency includes commit 4e64baf360a3a89bd92582f59344c12b5c0bd3fd or a later upstream revision. For packaged deployments, use the vendor or distribution release that incorporates this fix, and rebuild/redeploy any applications, containers, virtual environments, or wheels that vendor or pin the vulnerable library. Independently of the library upgrade, disable static RSA key exchange cipher suites and allow only forward-secret TLS key exchange such as ECDHE or DHE. Prefer TLS 1.2 with ECDHE suites or TLS 1.3, where static RSA key exchange is not used. Rotate TLS private keys and certificates for high-sensitivity services if there is a credible possibility that encrypted traffic was captured while vulnerable RSA key exchange was enabled. Add rate limiting and monitoring for excessive failed TLS handshakes, but do not rely on rate limiting as a primary fix.

How to confirm the fix worked

Confirm dependency versions from all runtime artifacts, not only source manifests: inspect deployed containers, virtual environments, server images, Python wheels, and lockfiles for pyca/cryptography builds older than the fixed upstream commit. For Git-sourced dependencies, verify that 4e64baf360a3a89bd92582f59344c12b5c0bd3fd or a later commit is present. Validate TLS configuration externally using tools such as testssl.sh, nmap ssl-enum-ciphers, OpenSSL s_client, or a managed TLS scanner and confirm that no TLS_RSA_* cipher suites are accepted. Confirm TLS 1.3 or TLS 1.2 ECDHE/DHE suites are preferred. After patching, redeploy and restart all affected services, then re-run software composition analysis and TLS cipher scans against every exposed endpoint.

Typical attack path

1. Identify TLS services that use Python components or applications depending on pyca/cryptography.
2. Determine whether the service permits static RSA key exchange cipher suites such as TLS_RSA_* rather than only forward-secret suites.
3. Capture encrypted TLS sessions of interest from a network position or previously collected traffic.
4. Send many crafted TLS handshakes or RSA ciphertexts to the target service and observe timing, alert, or error differences.
5. Use the observed behavior as a decryption oracle to recover the TLS premaster secret for captured sessions.
6. Derive the session keys and decrypt captured TLS application traffic.
7. Use exposed data such as credentials, tokens, or sensitive records for follow-on access or intelligence gathering.

How to detect it

Confirming exploitation is difficult because successful exploitation can look like ordinary TLS handshake failures and may involve passive traffic capture that leaves no host artifact. Focus detection on exposure and suspicious oracle-like probing. Review TLS terminator, reverse proxy, application, load balancer, WAF, IDS, and packet-capture metadata for repeated failed handshakes, decrypt errors, bad record MAC alerts, illegal parameter alerts, or abrupt connection resets, especially when associated with RSA cipher suite negotiation attempts. Look for many short TLS connections from the same source, high ratios of handshake failures to successful requests, or scans enumerating TLS_RSA_* cipher suites. On hosts, review dependency inventories, SBOMs, lockfiles, and runtime package listings for vulnerable pyca/cryptography builds. If packet capture is available, search for ClientHello messages offering TLS_RSA_* suites and repeated failed handshakes to the same endpoint. Because no named threat actors or public exploitation campaigns are provided and the issue is not in KEV, treat detections as suspicious indicators requiring correlation rather than proof of compromise.

• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_*
• handshake failure
• decrypt error
• bad record mac
• bad_record_mac
• illegal parameter
• RSA decrypt failed
• decryption failed or bad record mac
• tlsv1 alert decrypt error
• sslv3 alert bad record mac
• cryptography
• 4e64baf360a3a89bd92582f59344c12b5c0bd3fd

What your security team should do

• Inventory all applications, services, containers, and appliances that include pyca/cryptography, including transitive Python dependencies.
• Prioritize internet-facing TLS termination points, authentication services, API gateways, and services carrying credentials, tokens, payment data, personal data, or regulated information.
• Upgrade pyca/cryptography to a release containing commit 4e64baf360a3a89bd92582f59344c12b5c0bd3fd or later, then rebuild and redeploy affected artifacts.
• Disable TLS static RSA key exchange cipher suites across load balancers, reverse proxies, application servers, and embedded TLS stacks.
• Run external TLS scans to confirm TLS_RSA_* cipher suites are no longer accepted.
• Review historical TLS logs for unusually high volumes of failed handshakes, decrypt errors, or probing of RSA cipher suites from the same sources.
• If sensitive traffic may have been captured, assess whether certificate/private-key rotation and downstream credential or token rotation are warranted.
• Add CI/CD policy checks to block vulnerable pyca/cryptography versions and legacy TLS RSA cipher suites in future deployments.