CVE-2026-63578 in bc-csharp
Summary
by MITRE • 10/02/2026
Allocation of resources without limits in password-based private-key decryption (PbeUtilities.GenerateCipherParameters) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply an encrypted private key, such as a PKCS#8 EncryptedPrivateKeyInfo or "ENCRYPTED PRIVATE KEY" PEM file, to cause a denial of service through CPU exhaustion via an iteration count close to 2^31, because the count is taken from the unauthenticated algorithm parameters without an upper bound and the key derivation runs before the password or the data can be checked. PKCS#5 PBES1 and PBES2 (PBKDF2), the PKCS#12 PBE algorithms and CMS password recipients (CmsPbeKey) are affected. Loading PKCS#12 files with Pkcs12Store is covered by CVE-2026-63572, and a zero or negative count with the PKCS#12 algorithms by CVE-2026-63575.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Legion of the Bouncy Castle Inc.'s bc-csharp library prior to version 2.7.0 represents a critical resource exhaustion flaw within its password-based private-key decryption mechanisms, specifically located in the PbeUtilities.GenerateCipherParameters function. This issue stems from an allocation of resources without proper limits or validation checks on input parameters provided by external sources. The core technical deficiency lies in how the library processes algorithm parameters for key derivation functions such as PKCS#5 PBES1 and PBES2 including PBKDF2, PKCS#12 PBE algorithms, and CMS password recipients via CmsPbeKey. When an attacker supplies a maliciously crafted encrypted private key formatted as either a PKCS#8 EncryptedPrivateKeyInfo or a PEM file containing ENCRYPTED PRIVATE KEY data, the library extracts iteration counts directly from unauthenticated algorithm parameters without enforcing any upper bounds. This lack of validation allows for the specification of extremely high values that trigger excessive computational workloads during the decryption process.
The operational impact of this flaw is severe denial of service through CPU exhaustion. Because the key derivation routine executes before verifying the correctness of the password or validating the integrity of the encrypted data, an attacker can force the system to perform computationally intensive operations regardless of whether the provided credentials are valid. By setting the iteration count close to 2^31, which is near the maximum limit for signed 32-bit integers in many programming environments including C#, the library enters a prolonged state of high CPU utilization. This behavior effectively ties up server resources and can lead to service unavailability for legitimate users who depend on the cryptographic services provided by this library. The vulnerability affects multiple components within the Bouncy Castle ecosystem that rely on password-based encryption schemes, making it a widespread risk across applications utilizing these specific cryptographic standards for secure key storage or transmission.
From a classification perspective, this vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as the application fails to restrict the consumption of computational resources based on untrusted input. It also relates to CWE-295: Improper Certificate Validation insofar as it involves processing cryptographic parameters without adequate verification before execution. In terms of attack vectors and tactics, this flaw supports techniques associated with MITRE ATT&CK T1496: Resource Hijacking, where an attacker consumes significant computing resources to degrade service availability or potentially mine cryptocurrency if the environment allows for such exploitation patterns over extended periods. The specific mechanism of executing expensive cryptographic operations prior to authentication checks is a common pattern in denial-of-service vulnerabilities affecting cryptographic libraries and highlights the importance of validating input constraints early in the processing pipeline.
Mitigation strategies primarily involve upgrading to version 2.7.0 or later of the bc-csharp library, where these bounds have been addressed by implementing strict limits on iteration counts derived from untrusted sources. For organizations unable to immediately upgrade, defensive coding practices should be adopted within application layers that consume this library. This includes validating and sanitizing any encrypted private key inputs before passing them to Bouncy Castle methods, ensuring that iteration parameters are constrained to reasonable maximums defined by industry standards such as NIST guidelines for PBKDF2 iterations. Additionally, implementing timeout mechanisms or circuit breakers around cryptographic operations can help mitigate the impact of resource exhaustion attacks in production environments where immediate patching is not feasible. It is also crucial to monitor system metrics related to CPU usage and memory consumption during decryption processes to detect anomalous behavior indicative of such exploitation attempts.
Related vulnerabilities within the same family include CVE-2026-63572, which addresses issues with loading PKCS#12 files using Pkcs12Store, and CVE-2026-63575, which covers cases where zero or negative iteration counts are specified for PKCS#12 algorithms. These related flaws underscore a broader pattern of insufficient input validation in older versions of the library regarding cryptographic parameter handling. Security teams should conduct comprehensive audits of their dependency trees to ensure all instances of Bouncy Castle cryptography components are updated to patched versions that enforce strict resource limits and validate algorithm parameters against known safe ranges before initiating computationally expensive key derivation processes.