CVE-2026-63568 in bc-csharp
Summary
by MITRE • 10/02/2026
Allocation of resources without limits or throttling in the CMP/CRMF password-based MAC verifier (PKMacBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service through CPU exhaustion via a CMP message or CRMF certificate request whose PBMParameter declares a very large iteration count, because PKMacBuilder enforced its iteration-count ceiling only when the caller had supplied an explicit maximum through the PKMacBuilder(IPKMacPrimitivesProvider, int) constructor. With any other constructor, ProtectedPkiMessage.Verify and CertificateRequestMessage.IsValidSigningKeyPop performed as many hash iterations as the sender requested, up to about 2^31, before the MAC could be checked.
Once again VulDB remains the best source for vulnerability data.
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 the Cryptographic Message Syntax (CMS) and Certificate Request Message Format (CRMF) processing components. Specifically, this issue resides in the password-based message authentication code verifier known as PKMacBuilder. The core technical deficiency lies in how iteration counts for key derivation functions are handled during the verification of incoming cryptographic messages. When a remote unauthenticated attacker submits a CMP or CRMF certificate request containing a PBMParameter with an excessively large iteration count, the system fails to enforce reasonable limits on computational effort unless specific constructor parameters were explicitly set by the application developer. This oversight allows malicious actors to trigger CPU exhaustion, leading directly to denial of service conditions for systems relying on this library for secure communication and certificate management.
From a technical perspective, the flaw stems from conditional logic within the PKMacBuilder class that only applies an iteration count ceiling when the instance is instantiated via the constructor accepting both IPKMacPrimitivesProvider and an integer maximum value. In scenarios where other constructors are utilized, which do not enforce this explicit cap, the verification process proceeds without restriction on the number of hash iterations performed by ProtectedPkiMessage.Verify or CertificateRequestMessage.IsValidSigningKeyPop methods. These methods will execute as many iterations as dictated by the sender's input, potentially reaching up to approximately two to the power of thirty-one operations before the message authentication code is validated. This unbounded execution path effectively transforms a standard cryptographic verification step into a vector for severe performance degradation or complete system unavailability due to CPU saturation.
The operational impact of this vulnerability is significant for any application that processes incoming CMP or CRMF messages without rigorous input validation prior to invoking these library functions. An attacker can remotely exploit this weakness by crafting malicious certificate requests with artificially inflated iteration counts, thereby forcing the target server to consume excessive computational resources. This type of attack aligns closely with CWE-770: Allocation of Resources Without Limits or Throttling and falls under the ATT&CK technique T1496: Resource Hijacking, where adversaries leverage system resources for denial of service rather than data exfiltration or privilege escalation. The lack of throttling means that even modestly sized but computationally expensive requests can overwhelm server capacity, disrupting legitimate services and potentially causing cascading failures in dependent systems.
Mitigation strategies must focus on both immediate patching and architectural hardening. The primary remediation is to upgrade the bc-csharp library to version 2.7.0 or later, where this logic has been corrected to enforce iteration limits regardless of the constructor used. For environments unable to immediately update, developers should implement strict input validation at the application layer to reject any CMP or CRMF messages containing PBMParameter values that exceed a predefined safe threshold before passing them to the cryptographic library. Additionally, integrating rate limiting and resource monitoring can help detect and mitigate such attacks in real-time by identifying unusual spikes in CPU usage associated with certificate verification processes. Ensuring that all instances of PKMacBuilder are initialized using constructors that explicitly define maximum iteration counts provides an additional layer of defense against this specific exploitation vector.