CVE-2026-42768

What it actually does

This flaw creates a potential Bleichenbacher-style adaptive chosen-ciphertext oracle in OpenSSL CMS/S/MIME decryption paths that use RSA PKCS#1 v1.5 key transport. If an application lets an attacker submit crafted CMS or PKCS#7/S/MIME messages and exposes distinguishable decryption errors or decrypted-output differences, the attacker may repeatedly query the vulnerable application to learn whether RSA padding was valid. Under the right conditions, this can allow decryption of RSA-encrypted content encrypted to the victim key, and in some theoretical scenarios can support forging PKCS#1 v1.5 signatures with the victim private key. The issue is specifically tied to CMS_decrypt() and PKCS7_decrypt() behavior around KeyTransRecipientInfo processing and recipient-certificate handling. OpenSSL rates the issue low because exploitation requires an uncommon application design that exposes a usable oracle to a remote attacker.

Why it matters to the business

Organizations using OpenSSL for S/MIME, CMS, or PKCS#7 message processing could face limited confidentiality risk if externally reachable services process attacker-supplied encrypted messages and reveal detailed decryption behavior. The most likely operational impact is exposure of encrypted message content or misuse of a private RSA key in niche workflows, rather than broad system compromise. The CVSS score is low, EPSS is very low and stable, there is no known exploitation maturity, and it is not in CISA KEV; however, systems that process untrusted encrypted email or CMS payloads at scale should still remediate because private-key oracle weaknesses can be difficult to detect after the fact.

How an attack unfolds

An attacker first identifies an application that accepts attacker-controlled CMS, PKCS#7, or S/MIME encrypted messages and uses OpenSSL CMS_decrypt() or PKCS7_decrypt() with RSA PKCS#1 v1.5 key transport. In one variant, the attacker crafts a message with multiple KeyTransRecipientInfo entries: one valid entry for the victim recipient and another probe ciphertext. If the application does not provide the recipient certificate and exposes different errors, the attacker can repeatedly vary the probe ciphertext and observe whether padding or decryption behavior changes. In the second variant, the application provides a recipient certificate, but the recipient is not found and fallback behavior combined with observable output/error differences provides the oracle. By sending many adaptive probes and observing responses, the attacker can gradually recover information about RSA ciphertexts encrypted to the victim key. Exploitation is high-complexity because it depends on detailed application behavior, observable error or output differences, and a large number of oracle queries.

How to fix it

Upgrade OpenSSL to a vendor release that includes the fix for CVE-2026-42768 when available for the deployed branch or operating-system package. Because no exact fixed versions were provided in the input, follow the OpenSSL project advisory and the relevant Linux distribution, appliance, container-image, or application vendor guidance for the corrected package version. Rebuild or restart applications that statically or dynamically link OpenSSL so they load the patched library. Where immediate patching is not possible, reduce exposure by preventing untrusted users from submitting CMS, PKCS#7, or S/MIME encrypted payloads to vulnerable services; avoid RSA PKCS#1 v1.5 key transport where feasible; prefer modern authenticated encryption and key agreement schemes; do not expose raw OpenSSL decryption errors to remote clients; normalize failure responses; rate-limit decryption attempts; and ensure applications provide the intended recipient certificate to CMS_decrypt() or PKCS7_decrypt() rather than relying on recipient iteration. The OpenSSL FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected because CMS and S/MIME processing occurs outside the FIPS module boundary, but applications using OpenSSL outside that boundary may still require updates.

How to confirm the fix worked

Inventory OpenSSL versions used by operating-system packages, containers, appliances, and applications, including statically linked binaries. Confirm whether any application accepts untrusted CMS, PKCS#7, or S/MIME encrypted messages and calls CMS_decrypt() or PKCS7_decrypt(). Validate remediation by confirming the OpenSSL package or embedded library version matches a vendor-fixed build and by restarting dependent services. For application-level validation, test that malformed or recipient-mismatched CMS/PKCS#7 messages return uniform errors, uniform status codes, and no distinguishable decrypted output. Review code paths to ensure detailed OpenSSL errors are logged internally only and are not returned to remote users. If source code is available, search for CMS_decrypt, PKCS7_decrypt, RSA_PKCS1_PADDING, and PKCS#1 v1.5 key transport usage in message-processing components.

Typical attack path

1. Find an application or service that accepts attacker-supplied CMS, PKCS#7, or S/MIME encrypted messages.
2. Confirm that the application uses OpenSSL CMS_decrypt() or PKCS7_decrypt() with RSA PKCS#1 v1.5 key transport.
3. Determine whether the application exposes distinguishable decryption errors, status codes, timing, or decrypted-output differences.
4. Submit crafted CMS/PKCS#7 messages containing controlled KeyTransRecipientInfo entries or recipient-mismatch conditions.
5. Adaptively modify RSA ciphertext probes based on the observed application responses.
6. Use the oracle responses to recover information about a target RSA-encrypted content-encryption key or other RSA ciphertext.
7. Use the recovered key material to decrypt protected content, or in theoretical scenarios, derive values useful for PKCS#1 v1.5 signature forgery.

How to detect it

Detection should focus on signs that an application was used as a decryption oracle. Review web, mail gateway, API, application, and reverse-proxy logs for high-volume repeated submissions of CMS, PKCS#7, or S/MIME encrypted content, especially from a small set of source IPs and followed by varied error responses. Look for repeated malformed S/MIME attachments, files with .p7m, .p7c, or .p7s extensions, MIME type application/pkcs7-mime, or Content-Type values containing smime-type=enveloped-data. Application logs may show repeated OpenSSL CMS/PKCS7 decryption failures, recipient-not-found conditions, padding failures, ASN.1 parse errors, or content decryption failures. Because successful oracle exploitation may not create a single definitive artifact, prioritize behavioral signals: many near-identical encrypted-message submissions, steadily changing ciphertext sizes or recipient-info structures, and client-visible differences in error code, response body, or response length. If a service is suspected to have exposed a usable oracle, preserve application logs, full request metadata, mail samples if available, TLS-terminating proxy logs, and private-key access/audit logs; then assess whether key rotation is required.

• CMS_decrypt
• PKCS7_decrypt
• application/pkcs7-mime
• application/x-pkcs7-mime
• smime-type=enveloped-data
• .p7m
• .p7c
• .p7s
• Content-Type: application/pkcs7-mime
• Content-Type: application/x-pkcs7-mime
• KeyTransRecipientInfo
• recipient not found
• bad decrypt
• pkcs decoding error
• padding check failed
• CMS routines
• PKCS7 routines
• S/MIME decryption failed
• CMS decryption failed
• PKCS7 decryption failed

What your security team should do

• Prioritize patching systems that parse inbound S/MIME, CMS, or PKCS#7 messages from external or untrusted senders.
• Inventory applications and third-party products that bundle OpenSSL, especially mail gateways, secure messaging products, document-signing tools, workflow engines, and custom CMS/S/MIME processors.
• Ask application owners whether CMS_decrypt() or PKCS7_decrypt() is used with attacker-supplied content and whether detailed decryption errors are exposed to clients.
• Apply vendor-fixed OpenSSL packages once available and rebuild/redeploy statically linked applications and container images.
• Normalize externally visible decryption failures so attackers cannot distinguish padding, recipient, content-encryption, or parsing failures.
• Add rate limiting and anomaly detection for repeated malformed CMS, PKCS#7, or S/MIME submissions from the same source.
• Review historical logs for bursts of CMS/S/MIME decryption failures, recipient mismatch errors, or repeated malformed encrypted message submissions.
• Treat private RSA keys used by any confirmed exploitable oracle as potentially exposed and plan key rotation if exploitation is suspected.