CVE-2026-42768: OpenSSL CMS Bleichenbacher Vulnerability

CVE-2026-42768 Overview

CVE-2026-42768 is a Bleichenbacher-style padding oracle vulnerability affecting the CMS_decrypt and PKCS7_decrypt functions in OpenSSL. An attacker who can submit crafted Cryptographic Message Syntax (CMS) or S/MIME messages to a vulnerable application and observe the resulting error codes or decryption output can use the victim's application as an adaptive-chosen-ciphertext oracle. This oracle enables decryption of arbitrary RSA ciphertexts encrypted to the victim's key, or forgery of PKCS#1 v1.5 signatures under that key. OpenSSL classifies this as Low severity because no known real-world applications expose the required oracle to a remote attacker. The issue is tracked under [CWE-514] (Covert Channel).

Critical Impact

An attacker with oracle access can recover plaintext from any RSA ciphertext encrypted to the victim's public key or forge PKCS#1 v1.5 signatures using the victim's private key.

Affected Products

• OpenSSL CMS message processing (CMS_decrypt)
• OpenSSL PKCS#7 message processing (PKCS7_decrypt)
• Applications using OpenSSL RSA PKCS#1 v1.5 Key Transport for S/MIME or CMS

Discovery Timeline

• 2026-06-09 - OpenSSL publishes security advisory
• 2026-06-09 - CVE-2026-42768 published to NVD
• 2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-42768

Vulnerability Analysis

The vulnerability is a classic Bleichenbacher adaptive-chosen-ciphertext attack (Bleichenbacher, CRYPTO '98) exposed through OpenSSL's CMS and S/MIME decryption APIs. The flaw enables an attacker to repeatedly query the decryption routine with crafted ciphertexts and learn whether each ciphertext produces valid PKCS#1 v1.5 padding. By observing differences in error codes or output, the attacker iteratively reconstructs RSA plaintexts or forges signatures.

Two variants exist. In the first, the application calls CMS_decrypt() or PKCS7_decrypt() without providing a recipient certificate. OpenSSL then iterates through every KeyTransRecipientInfo (KTRI) entry without stopping at the first success. An attacker authors a message with two KTRI entries: a legitimate one wrapping a Content Encryption Key (CEK) under the victim's public key, and a second containing a probe ciphertext. The error code returned for the probe leaks padding validity.

In the second variant, the application supplies a recipient certificate but the recipient is not found in the message. OpenSSL substitutes a random key, and an attacker who can distinguish both the error code and decryption result can still build the oracle. The FIPS modules in OpenSSL 4.0, 3.6, 3.5, and 3.4 are not affected because CMS and S/MIME processing occurs outside the FIPS module boundary.

Root Cause

Previous OpenSSL releases explicitly disabled the implicit rejection mechanism in EVP_PKEY_decrypt() for RSA PKCS#1 v1.5 Key Transport. Without implicit rejection, distinguishable error paths and outputs leaked padding validity to callers, producing the Bleichenbacher oracle.

Attack Vector

Exploitation requires network-reachable submission of crafted CMS or S/MIME messages and a feedback channel that exposes per-recipient error codes or decryption results. The attacker submits thousands to millions of adaptive queries, each refining the search interval over the RSA plaintext space until full key transport recovery or signature forgery is achieved. See the OpenSSL Security Advisory for technical detail.

// No verified exploitation code is available.
// The attack follows the standard Bleichenbacher 1998 adaptive
// chosen-ciphertext method against PKCS#1 v1.5 RSA key transport,
// adapted to use a malformed second KTRI entry in a CMS message
// to elicit a distinguishing error or output from the victim.

Detection Methods for CVE-2026-42768

Indicators of Compromise

• High volume of CMS or S/MIME decryption requests from a single source containing malformed or atypical KeyTransRecipientInfo structures.
• Repeated decryption failures returning distinguishable error codes to the same client over short time windows.
• Application logs showing iteration over multiple KTRI entries for messages received from untrusted senders.

Detection Strategies

• Inspect OpenSSL-linked application logs for elevated rates of CMS_decrypt or PKCS7_decrypt errors tied to a single remote identity.
• Use software composition analysis to identify deployed OpenSSL versions that lack the implicit rejection fix.
• Audit application code paths that surface raw decryption error codes to external callers and flag them for review.

Monitoring Recommendations

• Alert on anomalous spikes in S/MIME or CMS message processing volume from individual senders.
• Track outbound responses that differentiate between padding errors and decryption failures and treat that differentiation as a leak.
• Correlate web application gateway logs with mail or CMS processing services to identify reconnaissance against decryption endpoints.

How to Mitigate CVE-2026-42768

Immediate Actions Required

• Inventory all applications that link OpenSSL and invoke CMS_decrypt() or PKCS7_decrypt() and prioritize those that expose error codes to remote callers.
• Update OpenSSL to a release containing the implicit rejection fix referenced in the OpenSSL Security Advisory.
• Modify calling code to always supply a recipient certificate to CMS_decrypt() and PKCS7_decrypt() so the correct RecipientInfo is selected deterministically.

Patch Information

Fixes are committed upstream. See the OpenSSL commits a2ca7b2d, bbb151a8, dd683641, and f04b377b. The fix enables the implicit rejection mechanism from draft-irtf-cfrg-rsa-guidance in EVP_PKEY_decrypt() for RSA PKCS#1 v1.5 Key Transport, returning a deterministic synthetic plaintext on padding failure.

Workarounds

• Always pass a recipient certificate to CMS_decrypt() and PKCS7_decrypt() rather than letting OpenSSL iterate over every KTRI entry.
• Avoid exposing differentiated decryption error codes to untrusted callers and return a single generic failure indicator instead.
• Migrate away from RSA PKCS#1 v1.5 Key Transport to RSA-OAEP or modern key agreement where the protocol allows.

# Verify the OpenSSL version currently deployed
openssl version -a

# Example: ensure CMS_decrypt is called with a recipient certificate
# (pseudocode reminder, not a complete program)
# CMS_decrypt(cms, pkey, recipient_cert, NULL, out_bio, 0);