CVE-2026-63575 in bc-csharp
Summary
by MITRE • 10/02/2026
Loop with unreachable exit condition in the PKCS#12 key derivation (Pkcs12ParametersGenerator) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, to cause a denial of service through CPU exhaustion via an iteration count of zero or below, because the derivation loop ran until its counter equalled the count, so for such a count it wrapped through about 2^32 iterations before the MAC or the password could be checked. A 75-byte PFX file with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes.
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 implementation flaw within the PKCS#12 key derivation mechanism, specifically affecting the Pkcs12ParametersGenerator class. This security issue stems from an improper validation of iteration counts used during password-based encryption and decryption processes defined by the PKCS#12 standard. When processing a PKCS#12 (PFX) file or a PKCS#8 encrypted private key that utilizes a PKCS#12 password-based encryption algorithm, the library fails to adequately check whether the supplied iteration count is positive before initiating the cryptographic derivation loop. This oversight allows an attacker who can supply maliciously crafted input files to trigger a denial of service condition through extreme CPU exhaustion. The core technical flaw lies in the logic governing the key derivation function, which relies on a loop that continues until its internal counter equals the specified iteration count.
In standard PKCS#12 implementations, the iteration count is intended to slow down brute-force attacks by requiring significant computational effort for each password guess. However, when an attacker provides an iteration count of zero or a negative value, the underlying integer arithmetic in C# causes the loop condition to behave unexpectedly due to unsigned integer wrapping behavior. Specifically, if the counter starts at zero and attempts to reach a large negative number interpreted as a massive positive unsigned integer, it must wrap through approximately 2^32 iterations before the comparison becomes false or an exception is thrown. This results in the processor being occupied for many minutes with no productive outcome other than resource consumption. A proof of concept involving a mere seventy-five-byte PFX file containing a negative MacData iteration count was sufficient to keep the Pkcs12Store.Load method busy, demonstrating that even minimal input can cause significant disruption without requiring complex or large-scale data transmission.
The operational impact of this vulnerability is severe for any application relying on bc-csharp for handling encrypted private keys or PKCS#12 containers. Since the attack vector requires only the ability to supply a file or string containing the malicious iteration count, it poses a risk in scenarios where user-uploaded certificates are processed automatically without rigorous pre-validation. The resulting denial of service can lead to application unresponsiveness, server resource depletion, and potential cascading failures in systems dependent on timely cryptographic operations. This aligns with CWE-835, which describes the use of a loop with an unreachable exit condition, as well as CWE-770, concerning allocation of resources without limits or throttling. From an offensive security perspective, this technique is consistent with ATT&CK tactic T1499, Endpoint Denial of Service, specifically under methods involving resource exhaustion via computational complexity.
Mitigation for this vulnerability requires immediate updates to the bc-csharp library version 2.7.0 or later, where the developers have addressed the logic error by ensuring that iteration counts are validated as positive integers before being passed into the derivation loop. For systems unable to update immediately, defensive coding practices should be implemented at the application layer. Developers must explicitly validate all integer parameters related to cryptographic iterations, ensuring they fall within expected positive ranges derived from RFC 7292 standards for PKCS#12. Additionally, implementing timeouts on cryptographic operations and monitoring CPU usage spikes can help detect such attacks in real-time. It is crucial that input validation occurs before any heavy computational work begins, thereby preventing the execution of malicious loops entirely rather than attempting to mitigate their effects after they have started.