Bc Csharp
Monthly
Denial of service in the Legion of the Bouncy Castle C# library (bc-csharp) affects all versions before 2.7.0, where quadratic CPU work in X.509 distinguished-name string conversion lets a remote unauthenticated attacker exhaust a server's CPU with a single crafted certificate, CRL, certification request, or other DN-bearing structure containing a long attribute value of characters that require RFC 4514 escaping. Exposure requires that the application actually converts the untrusted name to a string via X509Name.ToString / IetfUtilities.ValueToString (for logging or display) or compares it with IetfUtilities.RdnAreEqual, as PKIX path validation does when enforcing directoryName name constraints; merely parsing the certificate is not enough. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, but a vendor patch is available and the availability-only impact (CVSS:4.0 8.7 / assessed CVSS:3.1 7.5, A:H) makes application-level exposure the decisive risk factor.
Memory exhaustion in Bouncy Castle C# (bc-csharp) before 2.7.0 allows a remote, unauthenticated attacker to cause a denial of service against applications that verify HSS/LMS (RFC 8554) signatures using an attacker-supplied public key, because the HSS level count L is parsed without being bounded and then drives a huge array allocation during signature parsing - a single verification can commit roughly 17 GB of memory or terminate with an OutOfMemoryException. Impact is availability-only (CVSS 4.0 base 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): no confidentiality or integrity loss, and no authentication or user interaction is required. Exposure is bounded by the fact that HSS/LMS is a niche post-quantum feature, so only deployments that parse untrusted HSS keys and then verify signatures are affected; no public exploit identified at time of analysis, and no evidence of confirmed active exploitation (no CISA KEV listing).
Certificates that should be rejected by PKIX name constraints are accepted by Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0, allowing an attacker who controls or can obtain end-entity certificates from a name-constrained intermediate CA to bypass excluded-subtree restrictions for email addresses, DNS names, and URI hosts by appending a trailing dot (e.g., 'victim.example.'), which the vulnerable PkixNameConstraintValidator compared without stripping the RFC 1034 root-label dot. Exploitation requires that the victim relying party performs PKIX path validation with bc-csharp and actually enforces name constraints on that intermediate CA, so this is not remote exploitation of an arbitrary default deployment; the impact is integrity-only (a forged or impermissible certificate is accepted rather than data being leaked or destroyed). No public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) is associated.
Information disclosure in Bouncy Castle C# (bc-csharp) versions before 2.7.0 allows unauthenticated remote attackers to obtain plaintext from forged ciphertexts when an application decrypts into a caller-supplied buffer and subsequently observes that buffer after a failed authentication-tag check (e.g., through buffer reuse or logging). The vulnerability affects CcmBlockCipher and KCcmBlockCipher (DSTU 7624 CCM) only; methods returning newly allocated arrays are not vulnerable. No public exploit code or active exploitation has been identified, and the practical risk is conditional on the application exposing the failed decryption buffer, narrowing the attack surface despite the vendor-assigned CVSS 4.0 score of 8.2.
Uncontrolled recursion in Bouncy Castle C# (bc-csharp) before 2.7.0 allows unauthenticated remote attackers to crash or stall applications that parse attacker-supplied ASN.1 by submitting deeply nested constructed elements. About 2,000 nesting levels (roughly 8 KB of DER) exhaust the default ~1.5 MB .NET thread stack and raise a StackOverflowException that cannot be caught and terminates the process, while on threads with larger stacks the same input causes quadratic parse-time growth (about 9 seconds of CPU for 64 KB). Any code path that parses untrusted X.509 certificates or CRLs, CMS/PKCS#7, PKCS#8/PKCS#12, OCSP, or TLS Certificate messages is affected; no public exploit code has been identified at time of analysis, and the vendor has released a fix in version 2.7.0.
CPU-exhaustion denial of service in Bouncy Castle for C# (bc-csharp) before 2.7.0 allows attackers who can get an application to decrypt a supplied encrypted private key to force an effectively unbounded PBKDF2 key-derivation workload, because the iteration count (near 2^31) is read directly from unauthenticated algorithm parameters and the key derivation runs before either the password or the ciphertext can be checked. The CVSS vector carries PR:N, so no credentials are required, but exploitation hinges on the victim choosing to load or decrypt the attacker's key material (UI:P) - realistically only services that ingest externally controlled PKCS#8 EncryptedPrivateKeyInfo objects, "ENCRYPTED PRIVATE KEY" PEM files, or CMS password recipients (CmsPbeKey) are exposed. No public exploit code and no confirmed active exploitation were identified at time of analysis, and this is a moderate-severity availability issue rather than a confidentiality or integrity compromise; related PKCS#12 paths are tracked separately under CVE-2026-63572 (Pkcs12Store loading) and CVE-2026-63575 (zero/negative counts with PKCS#12 PBE algorithms).
PKIX certificate path validation in the Bouncy Castle C# library (bc-csharp) before 2.7.0 accepts certificates whose subject distinguished name, or directoryName subjectAltName, falls outside a name-constrained intermediate CA's permitted subtrees, breaking the RFC 5280 name-constraint trust boundary. An unauthenticated attacker who controls, or can obtain certificates from, a name-constrained intermediate CA already present in a chain the victim validates can craft a DN that prepends extra RDNs ahead of a copy of the permitted RDN sequence and have it accepted by PkixNameConstraintValidator.WithinDNSubtree. Vendor-released patches are available in the 2.7.0 codebase (commits 606e9153b97a265c70ca8293d21ec859344d7de8 and 75c3c576602886180ed92a63c89419e3bd63b392), and no public exploit code has been identified at time of analysis; exploitation is gated by the precondition that a name-constrained CA must already be positioned in the validated chain, so environments that do not enforce directoryName name constraints are unaffected.
Uniform Resource Identifier name-constraint bypass in Bouncy Castle .NET (bc-csharp) before 2.7.0 allows a name-constrained subordinate CA - or anyone able to obtain a certificate with an attacker-chosen subjectAltName URI from that CA - to evade permitted or excluded uniformResourceIdentifier constraints during RFC 5280 certification path validation. Because the PkixNameConstraintValidator helper ExtractHostFromURL slices the host out of the URI string without first isolating the RFC 3986 authority component, a crafted URI containing '@' (userinfo), ':' (port) or path/query/fragment delimiters produces a host value that differs from the URI's true host, so the leaf is judged unconstrained when it should not be; the vendor rates this CVSS 4.0 8.2, exploitation is unauthenticated per the vector (PR:N) but strongly conditional, and no public exploit code has been identified at time of analysis. Deployments that do not rely on bc-csharp for path validation or that never enforce URI-type name constraints on a subordinate CA are not affected.
Uncontrolled CPU consumption in Legion of the Bouncy Castle Inc.'s bc-csharp library before 2.7.0 lets an attacker who can supply a crafted PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, pin a CPU core for minutes at a time. The root cause is CWE-835, a loop with an unreachable exit condition: the PKCS#12 key-derivation loop in Pkcs12ParametersGenerator compared its counter with '!=' rather than '<', so an iteration count of zero or a negative value caused roughly 2^32 iterations to run before the MAC or password could ever be validated; a 75-byte PFX with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes. The impact is availability-only (CVSS 4.0 7.1, AV:N/AC:L/PR:N/UI:P, VA:H, with no confidentiality or integrity effect), so the flaw is an unauthenticated denial of service that depends on the victim application actually parsing attacker-controlled keystore data; only services that accept untrusted PFX/PKCS#8 input are realistically exposed, and no public exploit code was identified at time of analysis.
Denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows unauthenticated remote attackers to exhaust process memory by supplying crafted OpenPGP public keys, certificates, or signatures, because a subpacket header using the five-octet (0xFF) length form declares an oversized body length that is used directly to size a buffer before any subpacket data is read. The flaw lives in SignatureSubpacketsParser.ReadPacket and UserAttributeSubpacketsParser.ReadPacket (CWE-789, memory allocation with excessive size value) and is rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and an independently assessed CVSS 3.1 of A:H with no confidentiality or integrity impact; a handful of input bytes can demand an allocation of up to roughly 2 GB (the 32-bit length field permits up to ~4 GB in principle), so any service that imports or verifies untrusted PGP material is exposed. Vendor patches are available (bc-csharp 2.7.0) and no public exploit code has been identified at time of analysis, though the upstream regression test does illustrate the malicious packet format.
RSA PKCS#1 v1.5 key transport in the Bouncy Castle C# (bc-csharp) CMS implementation before 2.7.0 is vulnerable to a Bleichenbacher-style adaptive chosen-ciphertext attack that can recover the content-encryption key - and hence the plaintext - of a captured CMS EnvelopedData message. The observable discrepancy is that a key-transport ciphertext with invalid PKCS#1 v1.5 padding is rejected inside KeyTransRecipientInformation.UnwrapKey with a distinct 'bad padding in message' CmsException, instead of being silently replaced by a random key, so a malformed ciphertext can be distinguished from a well-padded one that only fails later during content decryption. The attack is unauthenticated (PR:N in both the CVSS 4.0 and the assessed CVSS 3.1 vectors) but highly conditional: the attacker must already hold a captured message, must have access to an application that decrypts attacker-submitted messages with the recipient's RSA private key, and must be able to observe the padding-versus-content error distinction across a very large number of adaptively modified ciphertexts - no public exploit code was identified at time of analysis, and the vendor fixed the issue in 2.7.0.
CPU exhaustion denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 lets unauthenticated remote attackers tie up a process by supplying a crafted PKCS#12 (PFX) keystore. Pkcs12Store.Load and Pkcs12Utilities.ConvertToDefiniteLength take the key-derivation iteration count straight from the file - in MacData or in the PBE parameters of an encrypted SafeContents or shrouded key bag - without an upper bound, so a count approaching 2^31 forces enormous key-derivation work before the MAC or password is ever validated (PR:N per the assessed CVSS:3.1 vector). Exploitation is not autonomous: the assessed UI:R/UI:P condition means some victim application or user must actually accept and load the malicious keystore, so no public exploit code has been identified at time of analysis and there is no CISA KEV listing; this is a genuine but moderate-priority availability issue rather than remote code execution despite the 7.1 CVSS 4.0 score.
Forged X.509 attribute certificates are accepted as valid by Legion of the Bouncy Castle Inc. bc-csharp versions before 2.7.0, because the PkixAttrCertPathValidator (and PkixAttrCertPathBuilder) never verifies the attribute certificate's signature against the issuer's public key. An unauthenticated remote attacker can therefore supply an attribute certificate that names a trusted attribute authority as issuer without being signed by it, and any application that grants roles or privileges based on that certificate's attributes will act on the attacker's forged claims. Only applications that use these specific classes to validate attribute certificates and derive authorization decisions from them are affected; no public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV). The vendor has released a fix in version 2.7.0.
Denial of service in the Legion of the Bouncy Castle C# library (bc-csharp) before 2.7.0: Pkcs12Store.GetCertificateChain follows AuthorityKeyIdentifier issuer links without tracking already-visited certificates, so a crafted PKCS#12 file containing certificates that reference each other in a cycle drives the chain-building loop to run indefinitely, consuming CPU and memory until an OutOfMemoryException is thrown. Applications are affected only if they load an attacker-supplied PKCS#12 keystore and then request a key entry's certificate chain; the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) indicates no authentication is needed but some user or process interaction is required to feed in the malicious file, and the impact is confined to availability. No public exploit identified at time of analysis, and the upstream fix commit ships a crafted cyclic keystore as a regression test fixture rather than as released exploit tooling.
Crafted small-order or out-of-range Diffie-Hellman values passed to DHAgreement.CalculateAgreement in Bouncy Castle C# (bc-csharp) before 2.7.0 let an on-path attacker or malicious peer defeat the key authentication MTI/A0 is designed to provide and, when the local party reuses a static DH private key, learn that key modulo the small factors of p-1 - with full recovery possible in groups where p-1 has many small prime factors. The issue is unauthenticated (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), and exploitation is not opportunistic: it works only where an application calls DHAgreement directly in an MTI/A0 two-pass flow, and it requires a protocol peer or on-path attacker able to inject a crafted 'message' or public-key value; higher-level Bouncy Castle protocol wrappers are unaffected. No public exploit code or confirmed active exploitation was identified at time of analysis, and the independent assessment rates real-world blast radius as narrower than the 9.1 CVSS 4.0 base score suggests because of the narrow direct-caller API surface, the static-key reuse prerequisite, and the dependence on weak group parameters for complete key recovery.
Denial of service in Legion of the Bouncy Castle's C# cryptography library (bc-csharp) before 2.7.0 lets an unauthenticated remote attacker exhaust server CPU by sending a CMP message or CRMF certificate request whose PBMParameter declares an iteration count as large as roughly 2^31; the library then performs that many hash iterations before it can even check the password-based MAC. Only deployments that accept untrusted inbound CMP/CRMF traffic and process it through ProtectedPkiMessage.Verify or CertificateRequestMessage.IsValidSigningKeyPop using a PKMacBuilder constructed without an explicit iteration ceiling are exposed - applications that already pass an explicit maximum are not affected, and general bc-csharp use (TLS, signing, hashing) never reaches the vulnerable path. Impact is availability-only (CVSS 4.0 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no public exploit identified at time of analysis, and a vendor-released fix exists in bc-csharp 2.7.0.
Observable padding discrepancy in the IES/ECIES decryption path of Bouncy Castle C# (bc-csharp) before 2.7.0 lets an unauthenticated remote attacker who has captured a valid ciphertext recover its plaintext through a CBC padding-oracle attack, because IesEngine.DecryptBlock strips padding and reports a distinguishable error before the MAC is checked. Exploitation requires non-default application behavior: IesEngine must be constructed directly with a padded block cipher such as AES-CBC with PKCS#7 padding, and the attacker must be able to repeatedly submit modified ciphertexts for decryption under the same static key pair and distinguish padding failures from MAC failures; stream-mode IES and standard ephemeral ECIES usage are explicitly unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the vendor CVSS 4.0 score of 8.2 is materially moderated by these prerequisites, which our independent assessment rates as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N.
Memory-exhaustion denial of service in the C# DTLS implementation of Bouncy Castle (bc-csharp) before 2.7.0 lets a remote, unauthenticated DTLS peer crash or stall a process by driving unbounded handshake-fragment reassembly buffers. A crafted fragment header can declare a message length of nearly 16 MB; because the reassembler is sized from that attacker-controlled 24-bit length before any check against the negotiated maximum handshake message size, a payload-free fragment forces an allocation of roughly 16 MB, and up to 16 pending messages per handshake multiply this toward hundreds of MB per unauthenticated connection, all before the handshake is authenticated. DTLS servers and DTLS clients built on bc-csharp are both affected, while pure TLS usage is explicitly not; no public exploit code has been identified at time of analysis, and the issue is rated CVSS 4.0 8.7 / CVSS 3.1 8.7 (AV:N/AC:L/PR:N/UI:N, availability-only impact).
Forgery of encrypted messages is possible in Legion of the Bouncy Castle Inc.'s bc-csharp (Bouncy Castle C#) before 2.7.0 when an IesEngine is constructed without a block cipher and initialised in static-static mode, because the keystream produced by the key-derivation function reveals the message authentication key for any message shorter than one the attacker has already observed. An unauthenticated remote attacker who possesses one ciphertext together with its known plaintext can therefore compute the MAC key and submit a crafted ciphertext and tag that the recipient accepts as authentic, although the forgery is confined to messages strictly shorter than the observed message and applications using standard ECIES with ephemeral sender keys or a block-cipher mode are unaffected. Vendor patch available: the defect is corrected in bc-csharp 2.7.0 via upstream commit f881400b761134160ec2a05fd27c3e569453788d, and no public exploit code was identified at time of analysis.
Authentication-tag forgery in Legion of the Bouncy Castle Inc. bc-csharp (Bouncy Castle C#) before 2.7.0 lets a remote, unauthenticated attacker who can obtain ciphertext-and-tag pairs for known or chosen plaintexts under at least two nonces forge a ciphertext that passes tag verification under a nonce that was never queried, because the DSTU 7624 (Kalyna) CCM implementation (KCcmBlockCipher) skipped the nonce-binding G1 block whenever a message carried no associated data. Only applications that call KCcmBlockCipher directly with empty AAD are affected, and the impact is integrity-only (VI:H, VC:N, VA:N), consistent with the vendor's CVSS 4.0 score of 8.7 and our independent CVSS 3.1 assessment of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. No public exploit was identified at time of analysis and the issue is not in CISA KEV, but the upstream fix commit publicly includes a regression test that assembles exactly such a cross-nonce forgery using three empty-AAD encryption queries, so the attack technique is documented; practical exposure is narrowed by the requirement for an encryption oracle and for empty-AAD usage of this specific mode.
On-path attackers who can intercept and modify CMS messages can silently tamper with AES-CCM-protected content that Legion of the Bouncy Castle Inc.'s bc-csharp library (versions before 2.7.0) decrypts. The root cause is that CcmParameters accepted any aes-ICVlen value from an untrusted AlgorithmIdentifier while CcmBlockCipher enforced the tag length only on the encryption path, so a decryption carrying a zero-length or very short tag compared an empty or truncated tag and accepted forged ciphertext without any detectable integrity failure; the same fix also hardens the AES-GCM CMS parameter handling. The reachable paths are ParameterUtilities.GetCipherParameters as used by CmsEnvelopedData and CmsEnvelopedDataParser for AES-CCM EnvelopedData, plus any caller that forwards an unchecked tag length into CcmBlockCipher for decryption. A vendor patch is available in 2.7.0 and the change is published as two commits plus a wiki advisory; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and because exploitation requires an attacker to already hold a network interception position (no remote-from-anywhere access, no authentication, no user interaction), the practical risk is a genuine but precondition-gated integrity/tampering issue rather than a broadly exploitable one.
Denial of service in the Legion of the Bouncy Castle C# library (bc-csharp) affects all versions before 2.7.0, where quadratic CPU work in X.509 distinguished-name string conversion lets a remote unauthenticated attacker exhaust a server's CPU with a single crafted certificate, CRL, certification request, or other DN-bearing structure containing a long attribute value of characters that require RFC 4514 escaping. Exposure requires that the application actually converts the untrusted name to a string via X509Name.ToString / IetfUtilities.ValueToString (for logging or display) or compares it with IetfUtilities.RdnAreEqual, as PKIX path validation does when enforcing directoryName name constraints; merely parsing the certificate is not enough. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, but a vendor patch is available and the availability-only impact (CVSS:4.0 8.7 / assessed CVSS:3.1 7.5, A:H) makes application-level exposure the decisive risk factor.
Memory exhaustion in Bouncy Castle C# (bc-csharp) before 2.7.0 allows a remote, unauthenticated attacker to cause a denial of service against applications that verify HSS/LMS (RFC 8554) signatures using an attacker-supplied public key, because the HSS level count L is parsed without being bounded and then drives a huge array allocation during signature parsing - a single verification can commit roughly 17 GB of memory or terminate with an OutOfMemoryException. Impact is availability-only (CVSS 4.0 base 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): no confidentiality or integrity loss, and no authentication or user interaction is required. Exposure is bounded by the fact that HSS/LMS is a niche post-quantum feature, so only deployments that parse untrusted HSS keys and then verify signatures are affected; no public exploit identified at time of analysis, and no evidence of confirmed active exploitation (no CISA KEV listing).
Certificates that should be rejected by PKIX name constraints are accepted by Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0, allowing an attacker who controls or can obtain end-entity certificates from a name-constrained intermediate CA to bypass excluded-subtree restrictions for email addresses, DNS names, and URI hosts by appending a trailing dot (e.g., 'victim.example.'), which the vulnerable PkixNameConstraintValidator compared without stripping the RFC 1034 root-label dot. Exploitation requires that the victim relying party performs PKIX path validation with bc-csharp and actually enforces name constraints on that intermediate CA, so this is not remote exploitation of an arbitrary default deployment; the impact is integrity-only (a forged or impermissible certificate is accepted rather than data being leaked or destroyed). No public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) is associated.
Information disclosure in Bouncy Castle C# (bc-csharp) versions before 2.7.0 allows unauthenticated remote attackers to obtain plaintext from forged ciphertexts when an application decrypts into a caller-supplied buffer and subsequently observes that buffer after a failed authentication-tag check (e.g., through buffer reuse or logging). The vulnerability affects CcmBlockCipher and KCcmBlockCipher (DSTU 7624 CCM) only; methods returning newly allocated arrays are not vulnerable. No public exploit code or active exploitation has been identified, and the practical risk is conditional on the application exposing the failed decryption buffer, narrowing the attack surface despite the vendor-assigned CVSS 4.0 score of 8.2.
Uncontrolled recursion in Bouncy Castle C# (bc-csharp) before 2.7.0 allows unauthenticated remote attackers to crash or stall applications that parse attacker-supplied ASN.1 by submitting deeply nested constructed elements. About 2,000 nesting levels (roughly 8 KB of DER) exhaust the default ~1.5 MB .NET thread stack and raise a StackOverflowException that cannot be caught and terminates the process, while on threads with larger stacks the same input causes quadratic parse-time growth (about 9 seconds of CPU for 64 KB). Any code path that parses untrusted X.509 certificates or CRLs, CMS/PKCS#7, PKCS#8/PKCS#12, OCSP, or TLS Certificate messages is affected; no public exploit code has been identified at time of analysis, and the vendor has released a fix in version 2.7.0.
CPU-exhaustion denial of service in Bouncy Castle for C# (bc-csharp) before 2.7.0 allows attackers who can get an application to decrypt a supplied encrypted private key to force an effectively unbounded PBKDF2 key-derivation workload, because the iteration count (near 2^31) is read directly from unauthenticated algorithm parameters and the key derivation runs before either the password or the ciphertext can be checked. The CVSS vector carries PR:N, so no credentials are required, but exploitation hinges on the victim choosing to load or decrypt the attacker's key material (UI:P) - realistically only services that ingest externally controlled PKCS#8 EncryptedPrivateKeyInfo objects, "ENCRYPTED PRIVATE KEY" PEM files, or CMS password recipients (CmsPbeKey) are exposed. No public exploit code and no confirmed active exploitation were identified at time of analysis, and this is a moderate-severity availability issue rather than a confidentiality or integrity compromise; related PKCS#12 paths are tracked separately under CVE-2026-63572 (Pkcs12Store loading) and CVE-2026-63575 (zero/negative counts with PKCS#12 PBE algorithms).
PKIX certificate path validation in the Bouncy Castle C# library (bc-csharp) before 2.7.0 accepts certificates whose subject distinguished name, or directoryName subjectAltName, falls outside a name-constrained intermediate CA's permitted subtrees, breaking the RFC 5280 name-constraint trust boundary. An unauthenticated attacker who controls, or can obtain certificates from, a name-constrained intermediate CA already present in a chain the victim validates can craft a DN that prepends extra RDNs ahead of a copy of the permitted RDN sequence and have it accepted by PkixNameConstraintValidator.WithinDNSubtree. Vendor-released patches are available in the 2.7.0 codebase (commits 606e9153b97a265c70ca8293d21ec859344d7de8 and 75c3c576602886180ed92a63c89419e3bd63b392), and no public exploit code has been identified at time of analysis; exploitation is gated by the precondition that a name-constrained CA must already be positioned in the validated chain, so environments that do not enforce directoryName name constraints are unaffected.
Uniform Resource Identifier name-constraint bypass in Bouncy Castle .NET (bc-csharp) before 2.7.0 allows a name-constrained subordinate CA - or anyone able to obtain a certificate with an attacker-chosen subjectAltName URI from that CA - to evade permitted or excluded uniformResourceIdentifier constraints during RFC 5280 certification path validation. Because the PkixNameConstraintValidator helper ExtractHostFromURL slices the host out of the URI string without first isolating the RFC 3986 authority component, a crafted URI containing '@' (userinfo), ':' (port) or path/query/fragment delimiters produces a host value that differs from the URI's true host, so the leaf is judged unconstrained when it should not be; the vendor rates this CVSS 4.0 8.2, exploitation is unauthenticated per the vector (PR:N) but strongly conditional, and no public exploit code has been identified at time of analysis. Deployments that do not rely on bc-csharp for path validation or that never enforce URI-type name constraints on a subordinate CA are not affected.
Uncontrolled CPU consumption in Legion of the Bouncy Castle Inc.'s bc-csharp library before 2.7.0 lets an attacker who can supply a crafted PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, pin a CPU core for minutes at a time. The root cause is CWE-835, a loop with an unreachable exit condition: the PKCS#12 key-derivation loop in Pkcs12ParametersGenerator compared its counter with '!=' rather than '<', so an iteration count of zero or a negative value caused roughly 2^32 iterations to run before the MAC or password could ever be validated; a 75-byte PFX with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes. The impact is availability-only (CVSS 4.0 7.1, AV:N/AC:L/PR:N/UI:P, VA:H, with no confidentiality or integrity effect), so the flaw is an unauthenticated denial of service that depends on the victim application actually parsing attacker-controlled keystore data; only services that accept untrusted PFX/PKCS#8 input are realistically exposed, and no public exploit code was identified at time of analysis.
Denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows unauthenticated remote attackers to exhaust process memory by supplying crafted OpenPGP public keys, certificates, or signatures, because a subpacket header using the five-octet (0xFF) length form declares an oversized body length that is used directly to size a buffer before any subpacket data is read. The flaw lives in SignatureSubpacketsParser.ReadPacket and UserAttributeSubpacketsParser.ReadPacket (CWE-789, memory allocation with excessive size value) and is rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and an independently assessed CVSS 3.1 of A:H with no confidentiality or integrity impact; a handful of input bytes can demand an allocation of up to roughly 2 GB (the 32-bit length field permits up to ~4 GB in principle), so any service that imports or verifies untrusted PGP material is exposed. Vendor patches are available (bc-csharp 2.7.0) and no public exploit code has been identified at time of analysis, though the upstream regression test does illustrate the malicious packet format.
RSA PKCS#1 v1.5 key transport in the Bouncy Castle C# (bc-csharp) CMS implementation before 2.7.0 is vulnerable to a Bleichenbacher-style adaptive chosen-ciphertext attack that can recover the content-encryption key - and hence the plaintext - of a captured CMS EnvelopedData message. The observable discrepancy is that a key-transport ciphertext with invalid PKCS#1 v1.5 padding is rejected inside KeyTransRecipientInformation.UnwrapKey with a distinct 'bad padding in message' CmsException, instead of being silently replaced by a random key, so a malformed ciphertext can be distinguished from a well-padded one that only fails later during content decryption. The attack is unauthenticated (PR:N in both the CVSS 4.0 and the assessed CVSS 3.1 vectors) but highly conditional: the attacker must already hold a captured message, must have access to an application that decrypts attacker-submitted messages with the recipient's RSA private key, and must be able to observe the padding-versus-content error distinction across a very large number of adaptively modified ciphertexts - no public exploit code was identified at time of analysis, and the vendor fixed the issue in 2.7.0.
CPU exhaustion denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 lets unauthenticated remote attackers tie up a process by supplying a crafted PKCS#12 (PFX) keystore. Pkcs12Store.Load and Pkcs12Utilities.ConvertToDefiniteLength take the key-derivation iteration count straight from the file - in MacData or in the PBE parameters of an encrypted SafeContents or shrouded key bag - without an upper bound, so a count approaching 2^31 forces enormous key-derivation work before the MAC or password is ever validated (PR:N per the assessed CVSS:3.1 vector). Exploitation is not autonomous: the assessed UI:R/UI:P condition means some victim application or user must actually accept and load the malicious keystore, so no public exploit code has been identified at time of analysis and there is no CISA KEV listing; this is a genuine but moderate-priority availability issue rather than remote code execution despite the 7.1 CVSS 4.0 score.
Forged X.509 attribute certificates are accepted as valid by Legion of the Bouncy Castle Inc. bc-csharp versions before 2.7.0, because the PkixAttrCertPathValidator (and PkixAttrCertPathBuilder) never verifies the attribute certificate's signature against the issuer's public key. An unauthenticated remote attacker can therefore supply an attribute certificate that names a trusted attribute authority as issuer without being signed by it, and any application that grants roles or privileges based on that certificate's attributes will act on the attacker's forged claims. Only applications that use these specific classes to validate attribute certificates and derive authorization decisions from them are affected; no public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV). The vendor has released a fix in version 2.7.0.
Denial of service in the Legion of the Bouncy Castle C# library (bc-csharp) before 2.7.0: Pkcs12Store.GetCertificateChain follows AuthorityKeyIdentifier issuer links without tracking already-visited certificates, so a crafted PKCS#12 file containing certificates that reference each other in a cycle drives the chain-building loop to run indefinitely, consuming CPU and memory until an OutOfMemoryException is thrown. Applications are affected only if they load an attacker-supplied PKCS#12 keystore and then request a key entry's certificate chain; the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) indicates no authentication is needed but some user or process interaction is required to feed in the malicious file, and the impact is confined to availability. No public exploit identified at time of analysis, and the upstream fix commit ships a crafted cyclic keystore as a regression test fixture rather than as released exploit tooling.
Crafted small-order or out-of-range Diffie-Hellman values passed to DHAgreement.CalculateAgreement in Bouncy Castle C# (bc-csharp) before 2.7.0 let an on-path attacker or malicious peer defeat the key authentication MTI/A0 is designed to provide and, when the local party reuses a static DH private key, learn that key modulo the small factors of p-1 - with full recovery possible in groups where p-1 has many small prime factors. The issue is unauthenticated (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), and exploitation is not opportunistic: it works only where an application calls DHAgreement directly in an MTI/A0 two-pass flow, and it requires a protocol peer or on-path attacker able to inject a crafted 'message' or public-key value; higher-level Bouncy Castle protocol wrappers are unaffected. No public exploit code or confirmed active exploitation was identified at time of analysis, and the independent assessment rates real-world blast radius as narrower than the 9.1 CVSS 4.0 base score suggests because of the narrow direct-caller API surface, the static-key reuse prerequisite, and the dependence on weak group parameters for complete key recovery.
Denial of service in Legion of the Bouncy Castle's C# cryptography library (bc-csharp) before 2.7.0 lets an unauthenticated remote attacker exhaust server CPU by sending a CMP message or CRMF certificate request whose PBMParameter declares an iteration count as large as roughly 2^31; the library then performs that many hash iterations before it can even check the password-based MAC. Only deployments that accept untrusted inbound CMP/CRMF traffic and process it through ProtectedPkiMessage.Verify or CertificateRequestMessage.IsValidSigningKeyPop using a PKMacBuilder constructed without an explicit iteration ceiling are exposed - applications that already pass an explicit maximum are not affected, and general bc-csharp use (TLS, signing, hashing) never reaches the vulnerable path. Impact is availability-only (CVSS 4.0 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no public exploit identified at time of analysis, and a vendor-released fix exists in bc-csharp 2.7.0.
Observable padding discrepancy in the IES/ECIES decryption path of Bouncy Castle C# (bc-csharp) before 2.7.0 lets an unauthenticated remote attacker who has captured a valid ciphertext recover its plaintext through a CBC padding-oracle attack, because IesEngine.DecryptBlock strips padding and reports a distinguishable error before the MAC is checked. Exploitation requires non-default application behavior: IesEngine must be constructed directly with a padded block cipher such as AES-CBC with PKCS#7 padding, and the attacker must be able to repeatedly submit modified ciphertexts for decryption under the same static key pair and distinguish padding failures from MAC failures; stream-mode IES and standard ephemeral ECIES usage are explicitly unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the vendor CVSS 4.0 score of 8.2 is materially moderated by these prerequisites, which our independent assessment rates as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N.
Memory-exhaustion denial of service in the C# DTLS implementation of Bouncy Castle (bc-csharp) before 2.7.0 lets a remote, unauthenticated DTLS peer crash or stall a process by driving unbounded handshake-fragment reassembly buffers. A crafted fragment header can declare a message length of nearly 16 MB; because the reassembler is sized from that attacker-controlled 24-bit length before any check against the negotiated maximum handshake message size, a payload-free fragment forces an allocation of roughly 16 MB, and up to 16 pending messages per handshake multiply this toward hundreds of MB per unauthenticated connection, all before the handshake is authenticated. DTLS servers and DTLS clients built on bc-csharp are both affected, while pure TLS usage is explicitly not; no public exploit code has been identified at time of analysis, and the issue is rated CVSS 4.0 8.7 / CVSS 3.1 8.7 (AV:N/AC:L/PR:N/UI:N, availability-only impact).
Forgery of encrypted messages is possible in Legion of the Bouncy Castle Inc.'s bc-csharp (Bouncy Castle C#) before 2.7.0 when an IesEngine is constructed without a block cipher and initialised in static-static mode, because the keystream produced by the key-derivation function reveals the message authentication key for any message shorter than one the attacker has already observed. An unauthenticated remote attacker who possesses one ciphertext together with its known plaintext can therefore compute the MAC key and submit a crafted ciphertext and tag that the recipient accepts as authentic, although the forgery is confined to messages strictly shorter than the observed message and applications using standard ECIES with ephemeral sender keys or a block-cipher mode are unaffected. Vendor patch available: the defect is corrected in bc-csharp 2.7.0 via upstream commit f881400b761134160ec2a05fd27c3e569453788d, and no public exploit code was identified at time of analysis.
Authentication-tag forgery in Legion of the Bouncy Castle Inc. bc-csharp (Bouncy Castle C#) before 2.7.0 lets a remote, unauthenticated attacker who can obtain ciphertext-and-tag pairs for known or chosen plaintexts under at least two nonces forge a ciphertext that passes tag verification under a nonce that was never queried, because the DSTU 7624 (Kalyna) CCM implementation (KCcmBlockCipher) skipped the nonce-binding G1 block whenever a message carried no associated data. Only applications that call KCcmBlockCipher directly with empty AAD are affected, and the impact is integrity-only (VI:H, VC:N, VA:N), consistent with the vendor's CVSS 4.0 score of 8.7 and our independent CVSS 3.1 assessment of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. No public exploit was identified at time of analysis and the issue is not in CISA KEV, but the upstream fix commit publicly includes a regression test that assembles exactly such a cross-nonce forgery using three empty-AAD encryption queries, so the attack technique is documented; practical exposure is narrowed by the requirement for an encryption oracle and for empty-AAD usage of this specific mode.
On-path attackers who can intercept and modify CMS messages can silently tamper with AES-CCM-protected content that Legion of the Bouncy Castle Inc.'s bc-csharp library (versions before 2.7.0) decrypts. The root cause is that CcmParameters accepted any aes-ICVlen value from an untrusted AlgorithmIdentifier while CcmBlockCipher enforced the tag length only on the encryption path, so a decryption carrying a zero-length or very short tag compared an empty or truncated tag and accepted forged ciphertext without any detectable integrity failure; the same fix also hardens the AES-GCM CMS parameter handling. The reachable paths are ParameterUtilities.GetCipherParameters as used by CmsEnvelopedData and CmsEnvelopedDataParser for AES-CCM EnvelopedData, plus any caller that forwards an unchecked tag length into CcmBlockCipher for decryption. A vendor patch is available in 2.7.0 and the change is published as two commits plus a wiki advisory; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and because exploitation requires an attacker to already hold a network interception position (no remote-from-anywhere access, no authentication, no user interaction), the practical risk is a genuine but precondition-gated integrity/tampering issue rather than a broadly exploitable one.