Skip to content

CVE 2026 63573

Jump to bottom
Peter Dettman edited this page Oct 1, 2026 · 1 revision

CVE-2026-63573

Issue affecting: BC C# .NET 2.6.2 and earlier, and the 2.7.0-beta.98 pre-release.

Fixed versions: BC C# .NET 2.7.0

Platform affected: All CLRs.

When decrypting CMS EnvelopedData (for example an S/MIME message) for a recipient whose content-encryption key was transported with RSA PKCS#1 v1.5 (the rsaEncryption algorithm), KeyTransRecipientInformation rejected a key-transport ciphertext with invalid padding straight away, with a CmsException carrying the message "bad padding in message.". A correctly padded ciphertext instead went on to content decryption and failed, if at all, only there. An application that decrypts messages from untrusted parties and lets them tell these two outcomes apart, whether through the error it returns, its behaviour or its timing, therefore acts as a Bleichenbacher padding oracle for its RSA key. The same applies to key-transport recipients of CMS AuthenticatedData.

An attacker who has captured a message encrypted to that key, and who can submit a large number of modified messages (typically thousands to millions) to such an application, can use the oracle to decrypt the captured message's content-encryption key and so read the message. The private key itself is not disclosed. Because the oracle works on raw RSA values, a message whose key was wrapped for the same RSA key with RSA-OAEP can be attacked in the same way, as long as the application accepts rsaEncryption recipients.

BC C# .NET 2.7.0 unwraps rsaEncryption recipients in constant time against the key length of the content-encryption algorithm and, if the padding is invalid, continues with a random key instead of raising an error, so a tampered key-transport ciphertext fails at content decryption in the same way as any other wrong key. This requires a content-encryption algorithm with a fixed key length: AES, ARIA, Camellia, DES, three-key Triple-DES, IDEA or SEED. For any other algorithm, for example RC2, RC4, CAST5, or an HMAC algorithm in AuthenticatedData, rsaEncryption recipients are now rejected by default with a CmsException. The previous behaviour, oracle included, can be restored by setting the property "Org.BouncyCastle.Cms.AllowLenientRsaPkcs1" to true, either as an environment variable or per thread through Org.BouncyCastle.Utilities.Properties; this is not recommended where untrusted messages are decrypted. RSA-OAEP and key-agreement recipients are handled as before.

Earlier versions have no setting that removes the oracle, so upgrading is recommended. Where that is not immediately possible, an application whose senders all use RSA-OAEP or key agreement can refuse recipients whose KeyEncryptionAlgOid is rsaEncryption (1.2.840.113549.1.1.1) before calling GetContent or GetContentStream, which closes the oracle. Otherwise every decryption failure, during key unwrap or content decryption alike, should be handled and reported identically and without detail to the sender, although a timing difference may remain.

Fix Commits:

Credit: Discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.

Clone this wiki locally