Bouncy Castle C# CVE-2026-63570

Exploitation requires that the application (1) loads an attacker-controlled PKCS#12 file into a bc-csharp Pkcs12Store and (2) subsequently calls GetCertificateChain for a key entry - the malicious file must contain certificates whose AuthorityKeyIdentifier extensions reference each other to form an issuer cycle (or otherwise link cyclically). The signature of the linked issuers is never checked, so no valid CA trust is needed. Limiting factors: the UI:P requirement means a trigger is needed - an application or operator must actually import the untrusted keystore and request its chain; deployments that only process trusted/internal PKCS#12 files, or that never call GetCertificateChain, are not exposed. No authentication is required (PR:N).

This is a genuine but bounded denial-of-service issue, not a code-execution or data-exposure threat. The CVSS 4.0 base score of 7.1 is driven entirely by availability impact (VA:H) with no confidentiality or integrity effect (VC:N/VI:N), reflecting CWE-835 (infinite loop) exhausting CPU and memory until an OutOfMemoryException. The vector shows AV:N, AC:L, AT:N, PR:N but UI:P (passive user interaction) - exploitation is network-reachable and needs no attacker privileges, but it is NOT fully automatic: an application must actually load the attacker-supplied PKCS#12 file and then call GetCertificateChain on a key entry. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation probability signals are absent; a regression test (ChainCycle) was committed with the fix but a reproducing keystore in a vendor test is not the same as a weaponized public exploit. Weighing these signals together: real-world priority is MODERATE - easy to trigger and remotely reachable where untrusted PKCS#12 files are processed, but limited to availability and gated on the application invoking the vulnerable chain-building path. Prioritize patching in services that ingest user-supplied keystores; deprioritize where PKCS#12 input is trusted/internal only.

An attacker crafts a PKCS#12 keystore containing two certificates whose AuthorityKeyIdentifier extensions each name the other as issuer, forming a cycle, and submits it to an application (e.g., a certificate-upload or keystore-import endpoint) built on bc-csharp. When the application loads the file and calls Pkcs12Store.GetCertificateChain, the chain-building loop follows the key-identifier links indefinitely because it keeps no record of visited certificates, never returning and consuming CPU and memory until the process throws an OutOfMemoryException. A vendor regression test demonstrates the cyclic keystore, but no independent public exploit was identified at time of analysis.