CVE 2026 63578

CVE-2026-63578

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 a password-protected private key is decrypted, the iteration count for the password-based key derivation is read from the key's own algorithm parameters. These parameters are not protected by the password, and the key derivation has to finish before the password, or the decrypted data, can be checked. PbeUtilities used the iteration count exactly as given, up to 2^31 - 1, so whoever produced the key also decided how much work any attempt to decrypt it would take.

Applications are exposed if they decrypt PKCS#8 EncryptedPrivateKeyInfo structures that come from an untrusted source, for example "ENCRYPTED PRIVATE KEY" PEM files read with PemReader, or keys passed to PrivateKeyFactory.DecryptKey or PrivateKeyInfoFactory.CreatePrivateKeyInfo. The PKCS#5 PBES1 and PBES2 (PBKDF2) schemes and the PKCS#12 password-based encryption algorithms were all affected, and so was the PBKDF2 key derivation for CMS password recipients (CmsPbeKey). A zero or negative count with the PKCS#12 algorithms is covered separately by CVE-2026-63575. A crafted key of about a hundred bytes keeps the decrypting thread busy for roughly half an hour or longer on a current desktop CPU, whatever password is supplied, and the caller has no way to cancel the work. Repeated submissions can tie up every worker thread. Loading PKCS#12 (PFX) files with Pkcs12Store, including the shrouded keys and encrypted contents inside them, is covered separately by CVE-2026-63572.

BC C# .NET 2.7.0 checks the iteration count before any key derivation is done. For PBES1, PBES2 and CMS password recipients the limit is set by the property "Org.BouncyCastle.Pbe.MaxIterationCount", and for the PKCS#12 algorithms by "Org.BouncyCastle.Pkcs12.MaxIterationCount". Both default to 5,000,000 and can be set either as an environment variable or per thread through Org.BouncyCastle.Utilities.Properties. A larger count is rejected with an ArgumentException, or an InvalidOperationException for the PKCS#12 algorithms. The same limits apply when keys are encrypted through PbeUtilities or EncryptedPrivateKeyInfoFactory, so applications that deliberately use more than 5,000,000 iterations need to raise them.

Earlier versions have no setting that limits the iteration count, so upgrading is recommended. Where that is not immediately possible, applications can parse the EncryptedPrivateKeyInfo (or the CMS PasswordRecipientInfo) themselves and reject an iteration count below 1 or larger than they expect before passing the structure to Bouncy Castle.

The corresponding issue in BC Java was fixed in BC Java 1.85 (CVE-2026-15055).

Fix Commits:

• https://github.com/bcgit/bc-csharp/commit/c00fc018fca89c077c64dd2a2a2eb00ae7d97241 (limits the PBES2 iteration count)
• https://github.com/bcgit/bc-csharp/commit/54ea0b179ee627027829b44c45d6dd32e575bd67 (limits the PBES1 iteration count)
• https://github.com/bcgit/bc-csharp/commit/7c0ed15f9783c9595b1a53f3900136461fd944f4 (limits the iteration count of the PKCS#12 algorithms)
• https://github.com/bcgit/bc-csharp/commit/34a7c05f719c91c024f285c6b420d3c00f8019dd (moves the limits to Org.BouncyCastle.Utilities.Properties)
• https://github.com/bcgit/bc-csharp/commit/b57165ecb7790ecea08273b219d52d80c12990e4 (applies the limit to CMS password recipients and sets the default to 5,000,000)

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