Bouncy Castle bc-csharp CVE-2026-63568

Exploitation requires that the target application process untrusted inbound CMP messages or CRMF certificate requests and invoke ProtectedPkiMessage.Verify or CertificateRequestMessage.IsValidSigningKeyPop using a PKMacBuilder created with a constructor OTHER than PKMacBuilder(IPKMacPrimitivesProvider, int) - i.e., one where no explicit iteration-count maximum was supplied; applications that already pass an explicit maximum are NOT affected. No authentication is needed (PR:N) because the oversized iteration count travels in the unauthenticated PBMParameter and is honored before the MAC is verified. Limiting factors: the affected version is bc-csharp before 2.7.0, and the vulnerable code path only executes in deployments that expose password-based-MAC CMP/CRMF handling - general bc-csharp usage (TLS, signing, hashing) does not reach it.

This is a genuine, well-characterized availability-only vulnerability rather than an inflated high-CVSS issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated, low-complexity reachability with no user interaction, and impact is cleanly scoped to availability (VC:N/VI:N/VA:H) - there is no confidentiality or integrity exposure, consistent with CWE-770 (uncontrolled resource allocation) and the source evidence showing a missing iteration-count ceiling. Key probabilistic signals are MISSING: no EPSS score was provided, so exploitation likelihood cannot be quantified, and the SSVC/exploitation fields in the vector are undefined (E:X). KEV status is not indicated (treat as not listed) and no POC is referenced, so this should be classified as no public exploit identified at time of analysis - but note the root cause is trivially triggerable (a single CMP/CRMF message with a large PBMParameter iteration count up to ~2^31), so weaponization effort is low despite the absence of published code. The realistic priority is MODERATE: easy to exploit and remotely reachable, but the blast radius is limited to applications that actually parse untrusted CMP messages or CRMF certificate requests using a PKMacBuilder instantiated without an explicit maximum, and the worst case is service CPU exhaustion, not compromise. Patch prioritization is warranted for any PKI/certificate-enrollment service built on bc-csharp.

An attacker sends a crafted CMP message or CRMF certificate request to a remote-facing certificate-enrollment or PKI endpoint built on bc-csharp, setting the PBMParameter iteration count to a very large value (up to ~2^31). When the server calls ProtectedPkiMessage.Verify or CertificateRequestMessage.IsValidSigningKeyPop with a default-constructed PKMacBuilder, it performs the full requested number of hash iterations before the MAC can even be checked, pinning a CPU core. No public exploit code is referenced, but the trigger is a single unauthenticated message and requires no special tooling.