Bouncy Castle C# EUVD-2026-91229

Exploitation requires that the target application parse and attempt to decrypt an attacker-supplied encrypted private key using bc-csharp before 2.7.0 - specifically a PKCS#8 EncryptedPrivateKeyInfo object, an 'ENCRYPTED PRIVATE KEY' PEM file, or a CMS password recipient (CmsPbeKey) routed through PbeUtilities.GenerateCipherParameters. The malicious iteration count (near 2^31) is read directly from the unauthenticated algorithm parameters, and the KDF executes before any password or ciphertext check, so no valid password or prior authentication is needed. The key LIMITING factor is user/application interaction (CVSS UI:P): the attacker cannot trigger this without the victim choosing to load/decrypt the supplied key, so only services that ingest externally-controlled encrypted keys are realistically exposed. Note Pkcs12Store loading is tracked separately under CVE-2026-63572 and zero/negative PKCS#12 counts under CVE-2026-63575.

This is a moderate-severity denial-of-service issue, not a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 7.1 driven entirely by availability impact - there is no confidentiality or integrity exposure, and no code execution. The vector reports network reachability and no privileges, but UI:P means exploitation is not fully autonomous: a victim application or user must actually load/decrypt the attacker-supplied encrypted private key, so this is a 'malicious input processing' DoS rather than a remotely-automatable service crash. No EPSS score was provided in the input, and there is no CISA KEV listing and no referenced proof-of-concept, so exploitation status is: no public exploit identified at time of analysis. The patch (bounding iteration count, default 10,000,000, configurable via Org.BouncyCastle.Pbe.MaxIterationCount) is confirmed available from the vendor with multiple commits and a regression test. SSVC-style reading: technical impact is partial (availability only, CPU exhaustion, not total system compromise) and exploitation is user-interaction-gated, lowering real-world urgency below what the 7.1 might suggest for teams that do not parse untrusted encrypted keys. Priority is genuine only for services that accept and decrypt externally-supplied PKCS#8/PEM encrypted keys or CMS password recipients; elsewhere it is low real-world risk.

An attacker crafts a PKCS#8 EncryptedPrivateKeyInfo or 'ENCRYPTED PRIVATE KEY' PEM file in which the PBES2/PBKDF2 (or PKCS#5 PBES1 / PKCS#12 PBE) parameters specify an iteration count near 2^31. When a service using bc-csharp before 2.7.0 attempts to decrypt this key via PbeUtilities.GenerateCipherParameters, the key-derivation function runs the attacker-chosen iteration count before the password or ciphertext is validated, pinning a CPU core and exhausting resources. No public exploit is identified at time of analysis, but the condition is trivial to construct by hand-editing the unauthenticated algorithm parameters.