Legion Of The Bouncy Castle Inc
Monthly
Keystream reuse in the native one-shot CTR packet cipher of Bouncy Castle for Java LTS before 2.73.13 allows remote attackers to recover plaintext from ciphertext alone, without knowledge of the key. Exploitation is unauthenticated but conditional: the application must use the native one-shot CTR path with a 13-, 14-, or 15-byte IV, leaving only a 1-, 2-, or 3-byte block counter (256, 65,536, or 16,777,216 blocks), and must pass a single input longer than that counter space so the counter wraps and the keystream restarts within the packet. The call returns the full input length with no exception, so the caller receives no signal that some bytes were transformed under a repeated keystream; the resulting two-time-pad condition permits plaintext recovery. No public exploit code has been identified at time of analysis, and the non-default short-IV native deployment requirement keeps realistic exposure narrow, which is why this is assessed as AC:H rather than trivially exploitable.
Bouncy Castle for Java before 1.86 fails to tie a Remove proposal in an MLS (RFC 9420) external commit to the joining party, allowing any holder of the group's public GroupInfo to evict an arbitrary member and take over that member's slot in the ratchet tree. Exploitation requires only that an application use the library's MLS module and accept external commits through the public Group.externalJoin / Group.handle API on an affected version; no group membership, credential, or user interaction is needed, and the missing credential check existed only in the gRPC interop harness, protecting none of the other API callers. The vendor rates this 8.7 (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N), and there is no public exploit identified at time of analysis, though the flaw is trivially reachable by anyone who legitimately receives GroupInfo.
Signature-verification bypass in Bouncy Castle for Java before 1.86 lets a phantom signer be accepted in BLS12-381 aggregate signature verification. The faulty BLS12_381BasicScheme.keyValidate() trusts the public key's own ECCurve object during the prime-order subgroup check, so an attacker-supplied ECPoint built on a foreign curve that merely shares BLS12-381's field characteristic - with its cofactor forged to 1 - passes validation despite not being a G1 point; in the pairing implementation such a point contributes the identity in the target group, so an aggregate signature verifies even though it contains no signature for that key/message pair. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key, since the standard 48-byte compressed-point decoder always supplies the canonical curve; no public exploit has been identified at time of analysis, and the assessed impact is high integrity compromise without confidentiality or availability loss (CVSS:4.0 base 7.1, network vector, no privileges required).
Bouncy Castle for Java's Messaging Layer Security (MLS, RFC 9420) implementation before 1.86 fails to bind an X.509 credential to a LeafNode's signature_key, allowing an unauthenticated remote attacker to present a victim's certificate while signing the LeafNode and KeyPackage with an unrelated key and be accepted under the victim's identity. In an MLS deployment that uses X.509 credentials and admits external commits without an independent credential-admission check, the attacker can be admitted as the victim, evict the victim via resynchronization (which compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. The flaw is rated CVSS 9.2 (CVSS:4.0) / 9.2-equivalent high impact with the vendor patch available in 1.86; no public exploit code or confirmed active exploitation was identified at time of analysis, and deployments using only basic credentials are explicitly unaffected. Note the assessed attack complexity is High because the MLS/X.509 path must be in use and the application must lack its own credential-admission validation.
Bouncy Castle for Java 1.81 through 1.85.2 fails to verify that a third-party OpenPGP signature was issued by a component key actually granted certification authority, so the high-level certificate API will attribute an attacker-made certification or trust delegation to the certificate's offline primary key. An attacker must already hold the private key of a restricted subkey (one bound only with SIGN_DATA, or a legacy RSA encryption subkey whose algorithm can still sign) that lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER flag; they can then issue a positive User ID certification or a full-trust depth-one direct-key delegation that getCertificationBy()/getDelegationBy() report as a valid chain, and any application treating isValid() as an identity or trusted-introducer decision will accept the forged assertion at the primary key's authority. The flaw is a privilege promotion of an already-compromised subkey rather than a key-recovery attack, no public exploit code has been identified at time of analysis, and vendor fixes are available in 1.86.
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
In-place encryption over a secret key buffer in Bouncy Castle for Java LTS before 2.73.13 can silently replace freshly produced ciphertext with the raw AES key, because native one-shot packet ciphers release read-only input arrays with JNI mode 0 and a later copy-back overwrites the output. The trigger is narrow and application-dependent-it requires the non-default pattern of passing the same Java array as both input and destination (for example, encrypting over KeyParameter.getKey()) on a JVM that copies rather than pins JNI array elements-so real-world exploitability is far lower than the 8.2 base score implies; bcprov, pure-Java packet ciphers, and native streaming modes are unaffected. No public exploit identified at time of analysis.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Certificate-validation bypass in Bouncy Castle for Java lets a PKIXCertPathReviewer accept an end-entity certificate that violates a NameConstraints extension imposed by its own issuing CA, causing isValidCertPath() to return true with an empty error list for a chain the real PKIX validator rejects. Affected are BC-Java before 1.86, BC-LTS-Java before 2.73.13, and BC-FJA (bcpkix-fips) before 1.0.13 / 2.0.13 / 2.1.13; exploitation requires an application that uses org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer (or the legacy org.bouncycastle.x509 copy) to make the trust decision rather than the unaffected CertPathValidator "PKIX"/"BC", and a chain whose leaf actually breaches the CA's permitted or excluded subtrees. No public exploit code has been identified at time of analysis, the vulnerability is unauthenticated (CVSS PR:N) per the vendor vector, and the vendor scores it CVSS 4.0 8.7 (High) for high integrity impact; note that an independent assessment rates attack complexity higher (CVSS 3.1 AV:N/AC:H) because the exposure depends entirely on non-default application architecture rather than on anything the attacker controls.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Timing side-channel leakage in Bouncy Castle for Java (bc-java) versions before 1.86 exposes private-key information from NTRU post-quantum KEM operations because three modular-reduction helpers used the '%' operator, which compiles to an integer division whose latency depends on the secret operand. Affected call paths include key generation (secret polynomials f and g), encapsulation (message polynomials r and m), and decapsulation (coefficients recovered from the private key), and the CVSS 4.0 base score is 8.2 (assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - confidentiality only). Exploitation requires the application to actually invoke NTRU KEM operations with a persistent/reused key and an attacker able to repeatedly measure operation timing with low jitter, so practical risk is limited to deployments that use NTRU and expose those operations to a co-located or low-latency timing observer; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV listing), but a vendor patch is available and should be applied.
Heap-exhaustion denial of service in the MLS implementation of Bouncy Castle for Java (bc-java) before 1.86, triggered by a single small PrivateMessage whose SenderData carries a wire-encoded uint32 leaf_index with its top bit set. Because that value is held in a signed int, it decodes as negative and passes the signed bounds checks in GroupKeySet.SecretTree.hasLeaf and Group.validateRemove, letting a sender outside the tree reach LeafIndex.directPath()/NodeIndex.parent() arithmetic that never terminates at the tree root and grows a node list until the JVM runs out of heap. Impact is confined to availability (CVSS 4.0 8.7 with VA:H and no confidentiality or integrity effect); group membership is a practical prerequisite since the triggering MLS message or Remove proposal must originate from a current group participant, and applications that do not use org.bouncycastle.mls are unaffected. No public exploit code identified at time of analysis and the issue is not in CISA KEV; the vendor has released a fix in Bouncy Castle 1.86.
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.
Cryptographic key material in Bouncy Castle for Java FIPS (BC-FJA) persists in the JVM heap far beyond its intended lifetime on Java 12 and later runtimes because the library's zeroisation scheme relies on Object.finalize(), a mechanism progressively de-emphasized since Java 9 and deprecated for removal in Java 18. Under load, the single finalizer thread cannot retire pending objects as fast as they are allocated, causing the queue to grow without bound - resulting in an OutOfMemoryError that crashes the application and defeating the cryptographic hygiene goal of prompt key zeroisation. No public exploit is identified at time of analysis; however, any network-accessible application built on BC-FJA prior to the fixed versions is exposed to both a remotely triggerable denial-of-service and prolonged in-memory residence of sensitive key material.
Unbounded retry loops in BC-FJA's JNI native entropy layer cause calling threads to hang indefinitely when Intel RDSEED or RDRAND instructions persistently fail, producing a non-interruptible thread-level denial of service in any Java FIPS application backed by bc-fips 2.1.x before 2.1.3. The affected JNI seeding routine re-issues the CPU entropy instruction without any iteration limit whenever the carry flag signals failure - a condition reproducible by hardware entropy source faults, DRBG exhaustion under heavy multi-core contention, or hypervisors that do not forward these Intel instructions to guest VMs. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the conditions are routinely present in virtualized environments where hypervisors commonly withhold RDRAND/RDSEED forwarding, making this a realistic operational risk for enterprise Java FIPS deployments in cloud or VM-based infrastructure.
Uncontrolled recursion in Bouncy Castle for Java's lazy ASN.1 parser enables remote unauthenticated denial of service across all three library release lines (bc-java, bc-lts-java, and bc-fja FIPS). When a LazyEncodedSequence is forced during tree traversal, it resets the nesting-depth guard to its configured maximum instead of continuing with the remaining depth budget, allowing crafted deeply-nested ASN.1 structures to bypass StreamUtil's recursion limit and trigger a StackOverflowError. No public exploit has been identified at time of analysis, but any Java application accepting externally-supplied ASN.1 data - TLS certificates, CMS signatures, PKCS structures - is potentially exposed without authentication.
RSA PKCS#1 v1.5 signature forgery is possible in Bouncy Castle for Java (bc-java before 1.85, bc-lts-java before 2.73.12) when the DigestInfo encoding omits the NULL AlgorithmIdentifier parameter. The off-by-two bytes in the RSADigestSigner comparison loop allows any forged signature whose DigestInfo matches all bytes except the final two of the message hash to pass verification as valid, achieving a high-integrity bypass. No public exploit has been identified at time of analysis, but the public patch commit includes a step-by-step test demonstrating the exact forgery technique, substantially lowering the bar to exploitation.
Heap exhaustion via uncontrolled memory allocation in Bouncy Castle for Java's MLS wire decoder allows remote unauthenticated attackers to crash any application using the bc-java MLS module. The MLSInputStream.readOpaque() method decodes an attacker-supplied Varint length field (up to 0x3FFFFFFF, approximately 1 GiB) and allocates that buffer before verifying the input stream actually contains that many bytes; a handful of concurrent few-byte crafted messages can exhaust the JVM heap. No public exploit has been identified at time of analysis and CISA KEV listing is absent, though the attack is trivially constructable from the published patch and regression test.
OpenPGP AEAD decryption in Bouncy Castle for Java silently bypasses the final authentication tag when plaintext is an exact multiple of the AEAD chunk length, allowing an attacker who can tamper with ciphertext to strip trailing plaintext chunks and have the truncated message accepted as cryptographically authentic. Affected libraries span bc-java before 1.85, bc-lts-java before 2.73.12, and all three active BC-FJA FIPS series before their respective bcpg-fips 1.0.13, 2.0.13, and 2.1.13 releases. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the CVSS 4.0 score of 8.7 (Integrity: High) reflects a complete and silent bypass of AEAD integrity guarantees for chunk-aligned messages with no downstream exception or warning.
IESEngine in Bouncy Castle for Java allows cross-message MAC forgery when stream mode is used with static key pairs, affecting bc-java before 1.85 and bc-lts-java before 2.73.12. The flaw stems from a length-dependent KDF output split: in the static-key path (no ephemeral V component), the MAC key K2 was placed at a byte offset equal to the message length after the keystream K1, so an observer of one known-plaintext encryption can recover K2 and forge valid ciphertext-plus-tag pairs for shorter messages. No public exploit beyond the vendor's own proof-of-concept regression test exists, and no CISA KEV listing is present at time of analysis.
Cross-nonce AEAD forgery in Bouncy Castle for Java's KCCMBlockCipher (DSTU 7624 CCM mode) allows an attacker with chosen-plaintext oracle access to forge valid authenticated ciphertext under an un-queried nonce when no associated authenticated data is present. All bc-java releases before 1.85 and bc-lts-java releases before 2.73.12 are affected. The G1 initialization block - which binds the nonce into the MAC under the DSTU 7624:2014 standard - was conditionally skipped when no AAD bytes were supplied, leaving the authentication tag independent of the nonce and breaking the core AEAD security guarantee. No public exploit has been independently released and this vulnerability is not listed in CISA KEV, though the fix commits include a working regression test that fully demonstrates the forgery technique.
CMS AuthEnvelopedData decryption in Bouncy Castle for Java fails to enforce a minimum AEAD authentication tag length, allowing a network attacker to supply a crafted CMS message carrying a truncated AES-GCM/CCM ICV (e.g., 32 bits instead of the standard 128 bits), effectively reducing the authentication space to the point where tag forgery becomes computationally feasible. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and all bc-fja (FIPS) 1.0.x/2.0.x/2.1.x series before their respective .12 patch releases. No public exploit or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.7 with VI:H reflects the high integrity impact of bypassing authenticated encryption guarantees.
Out-of-memory denial-of-service in Bouncy Castle for Java allows remote unauthenticated attackers to crash Java applications by submitting a crafted ASN.1 definite-length object with an inflated declared size. The ASN.1 parser in `DefiniteLengthInputStream.toByteArray()` allocated a full heap-sized byte array before reading any body bytes, meaning a few-byte header claiming a near-JVM-heap payload was sufficient to trigger OOM. All major Bouncy Castle release lines are affected - including the FIPS-certified BC-FJA variant - and a vendor patch is available; no public exploit code or CISA KEV listing exists at time of analysis.
CPU exhaustion in Bouncy Castle for Java allows remote attackers to cause denial of service by supplying X.500 distinguished name attribute values densely packed with RFC 4514 special characters or leading/trailing spaces. The root cause is a quadratic-time O(n²) escaping algorithm in `IETFUtils.valueToString()` that inserts backslashes into the buffer being actively scanned - triggerable through `X500Name.toString()`, `.equals()`, or `.hashCode()`, methods commonly invoked during TLS certificate and LDAP DN processing. No public exploit has been identified beyond the vendor's own regression test, and this vulnerability is not listed in CISA KEV, though the CVSS 4.0 score of 8.7 with AV:N/PR:N signals meaningful exposure for Internet-facing Java services.
Uncontrolled memory allocation in Bouncy Castle for Java's HSS public-key parser allows remote unauthenticated attackers to exhaust JVM heap memory by supplying a crafted public key with an arbitrarily large HSS level count (L value), causing denial of service during signature verification. All three product lines are affected: bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FIPS (bc-fja) before 2.0.2/2.1.3 depending on series. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the AV:N/AC:L/PR:N attack profile and Bouncy Castle's ubiquity as a Java crypto dependency make this a credible availability risk for any service accepting external HSS/LMS key material.
CCMBlockCipher in Bouncy Castle for Java decrypts ciphertext directly into the caller-supplied output buffer before verifying the authentication tag, leaving unverified CTR-decrypted plaintext in memory when tag verification fails and violating NIST SP 800-38C §6.2. Every edition - bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA across three active release lines (1.0.x, 2.0.x, 2.1.x) - is affected. Applications that reuse pooled byte buffers, log failure-path output, or otherwise expose the buffer on an authentication failure inadvertently become CTR decryption oracles, allowing attackers to submit forged ciphertexts and recover plaintext without possessing a valid authentication tag. No public exploit and no CISA KEV listing exist at time of analysis.
Certificate revocation-check bypass in the Bouncy Castle for Java (bc-java) PKIX provider allows a validly-signed OCSP response issued for one certificate to be accepted as proof-of-status for a different certificate, because the stapled response is not bound to the CertID of the certificate actually being checked. This means a revoked end-entity certificate can pass PKIXRevocationChecker validation when a 'good' OCSP response for another serial (e.g. the CA's) is supplied, defeating revocation enforcement in TLS/PKI clients that rely on OCSP stapling. Affected releases are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (FIPS) before 2.0.2 and 2.1.3; no public exploit identified at time of analysis and it is not listed in CISA KEV.
TLS hostname-verification bypass in the Bouncy Castle for Java JSSE provider (BCJSSE) ships the legacy certificate-CN fallback enabled by default, even though the vendor documentation states it is opt-in and gated behind the org.bouncycastle.jsse.client.checkCnFallback property. Affected are BC-Java before 1.85, BC-LTS before 2.73.12, and BC-FJA (FIPS) TLS module bctls-fips before 1.0.24, 2.0.24 and 2.1.24; a MITM-positioned attacker can present a SAN-less certificate whose Subject CN names the victim host and have it silently accepted, defeating name-constraint protections and enabling interception of TLS traffic (CWE-297). This carries a CVSS 4.0 base of 9.3, but there is no public exploit identified at time of analysis and it is not in CISA KEV.
Signature bypass in Bouncy Castle for Java allows any attacker-supplied content wrapped in a zero-signer CMS envelope to pass `CMSSignedData.verifySignatures()` without any valid cryptographic signature. The method iterates an empty signerInfos SET, falls through to a vacuous `return true`, and any application using it as its top-level authenticity check silently accepts unsigned attacker-controlled content as authenticated - a classic fail-open flaw (CWE-347). No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the attack primitive is trivially constructible using any standard CMS/PKCS#7 library.
Bouncy Castle for Java's OpenPGP session-key decryption path re-exposes the Mister-Zuccherato adaptive-chosen-ciphertext oracle by failing to suppress the legacy CFB 'quick check' on the PKESK/session-key route, enabling an attacker with decryption oracle access to recover plaintext from SEIPD v1 encrypted messages. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bcpg-fips) across the 1.0.X, 2.0.X, and 2.1.X series - three distinct product lines used broadly in enterprise and open-source Java applications. No public exploit or CISA KEV listing has been identified at time of analysis; however, the attack technique is well-established in cryptographic literature dating to the Mister-Zuccherato paper.
Signature forgery via back-dated signingTime in Bouncy Castle's S/MIME validator allows an attacker holding a revoked or expired signing certificate to have that certificate accepted as valid by unpatched validators. The SignedMailValidator in bc-java before 1.85, bc-lts-java before 2.73.12, and all bc-fja (FIPS) lines before their respective 1.0.7/2.0.7/2.1.7 fixes unconditionally used the signer-asserted CMS signingTime attribute as the PKIX path-validation date, making certificate expiry and revocation checks bypassable. No public exploit or CISA KEV listing exists at time of analysis, but the flaw is architecturally straightforward to exploit by any party that holds or has previously held a Bouncy Castle-validated signing certificate.
CMS AuthenticatedData integrity verification in Bouncy Castle for Java is bypassable when authenticated attributes (authAttrs) are present, allowing an attacker to substitute arbitrary content while the recipient MAC check passes without error. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA across the 1.0.x, 2.0.x, and 2.1.x series - all widely deployed in Java enterprise and FIPS environments. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VI:H) reflects unauthenticated remote exploitation with high integrity impact; no public exploit or CISA KEV listing is confirmed at time of analysis.
OpenPGP inline-signature policy enforcement in Bouncy Castle for Java silently discards rejection exceptions, causing signatures that use prohibited weak hash algorithms (MD5, SHA-1, RIPEMD-160) or otherwise violate the configured OpenPGPPolicy to be reported as cryptographically valid. Affected are bc-java before 1.85 and bcpg-fips (bc-fja) before 2.0.13; the detached-signature and prefixed-signature verification paths are not affected - only the inline one-pass path. A vendor patch is available; no public exploit code has been identified at time of analysis, though the CVSS 4.0 score of 8.7 reflects a high integrity impact driven by the unauthenticated network vector.
CPU exhaustion in Bouncy Castle for Java's MLS (Messaging Layer Security) implementation allows a network attacker to trigger unbounded HKDF key-derivation iterations by supplying a crafted 32-bit generation counter in an MLS message. The hash-ratchet in GroupKeySet.get(int generation) advances one HKDF step per skipped generation without any upper bound, so a maximally crafted counter forces up to ~4.29 billion derivation steps on the receiving process. Scored CVSS 4.0 at 8.7 with High availability impact and no authentication prerequisites per vendor scoring; no public exploit code or KEV listing has been identified at time of analysis.
Unbounded recursion in Bouncy Castle's OER (Octet Encoding Rules) parser enables remote unauthenticated denial-of-service against any Java application processing IEEE 1609.2 V2X messages. Because the IEEE 1609.2 schema is cyclic - an Ieee1609Dot2Data structure can nest inside its own SignedData payload - a few kilobytes of crafted input drive the parser into unbounded recursive descent, terminating in a JVM StackOverflowError. Critically, parsing occurs before signature verification, so no authentication or trust relationship is needed to trigger the crash. No public exploit has been identified at time of analysis, but the patch commit exposes two additional heap-exhaustion vectors alongside the primary recursion flaw, all reachable from the same pre-verification code path.
Memory exhaustion denial-of-service in Bouncy Castle's DTLS implementation allows remote unauthenticated attackers to crash or degrade Java applications by sending crafted handshake messages with inflated 24-bit length fields. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bctls-fips) before 1.0.24, 2.0.24, or 2.1.24 depending on the deployed branch. The buffer allocation occurs pre-authentication during the DTLS handshake reassembly phase - before any signature or Finished verification - making this exploitable without credentials against any exposed DTLS endpoint. No public exploit code has been identified and the vulnerability is not listed in CISA KEV.
Memory exhaustion in Bouncy Castle for Java's OpenPGP parser enables unauthenticated remote denial of service via a crafted User Attribute subpacket with an oversized length header. All Java applications importing untrusted OpenPGP certificates using bc-java before 1.85, bc-lts-java before 2.73.12, or BC-FJA (FIPS) in affected series are vulnerable to pre-authentication JVM heap exhaustion. No KEV listing or public exploit has been confirmed at time of analysis, but the zero-complexity unauthenticated network attack vector and CVSS 4.0 score of 8.7 signal high operational priority for services that accept OpenPGP certificates from external sources.
Private key recovery in Bouncy Castle for Java (bc-java before 1.85, bc-lts-java before 2.73.12) affects the DH agreement code path, where a peer-supplied public value is exponentiated with the local private key without full range/subgroup validation. A malicious protocol peer can submit small-order or out-of-range Diffie-Hellman elements to mount a small-subgroup confinement attack and, when the local private key is static/reused, gradually recover it via CRT - enabling decryption and impersonation. No public exploit identified at time of analysis; the fix is a vendor-released patch and the vulnerability is not listed in CISA KEV.
Bouncy Castle for Java's BKS keystore implementation silently accepted legacy version 0/1 keystores that derive a critically weak 16-bit HMAC integrity key - brute-forceable offline in milliseconds against the 65,536-value keyspace - allowing an attacker who can supply or tamper with a keystore file to forge the integrity MAC, inject rogue trusted certificates, and have the manipulated keystore accepted without error. All bc-java releases before 1.85 and bc-lts-java releases before 2.73.12 are affected. No public exploit code has been identified and this vulnerability does not appear in the CISA KEV catalog at time of analysis.
Bouncy Castle for Java's BKS and UBER keystore implementation crashes with an OutOfMemoryError when loading a crafted keystore because heap allocation from stream-declared lengths occurs before the HMAC integrity check. Any application calling KeyStore.load() with attacker-controlled BKS or UBER keystore data is affected - bc-java before 1.85 and bc-lts-java before 2.73.12. A POC was submitted alongside the report, confirming that a file of just a few dozen bytes declaring Integer.MAX_VALUE-length fields is sufficient to exhaust JVM heap regardless of heap configuration or supplied password. No public exploit identified at time of analysis beyond the researcher's POC referenced in the patch commit.
Certificate name-constraint bypass in Bouncy Castle for Java allows a crafted certificate to escape X.509 permitted/excluded subtree restrictions by appending a trailing dot to an rfc822Name (email) or URI host, or by prepending RDNs ahead of a permitted directoryName. Any relying party using BC's PKIXNameConstraintValidator (via CertPathValidator/CertPathBuilder) to enforce name constraints can be tricked into trusting an identity a constrained CA was never authorized to issue, enabling impersonation and effective authentication bypass. There is no public exploit identified at time of analysis, but the vendor rates it 9.3 (Critical) and a fix is available.
Pre-authentication resource exhaustion in Bouncy Castle BC-JAVA PGP modules (bcpg) allows remote attackers to trigger denial-of-service by exploiting unbounded AEAD chunk sizes, affecting all versions before 1.84. The maximum CVSS 4.0 score of 10.0 reflects complete compromise potential across confidentiality, integrity, and availability with no attack complexity, no authentication requirements, and network-based exploitation. No public exploit identified at time of analysis, though the attack s
Non-constant time comparison operations in the Legion of the Bouncy Castle BC-JAVA cryptographic library (core modules, versions 2.17.3 through 1.83) expose FrodoKEM private keys to timing side-channel attacks, enabling remote unauthenticated attackers to extract cryptographic secrets through statistical analysis of operation timing variations. CVSS 4.0 score of 10.0 reflects maximum confidentiality and integrity impact across system and subsequent contexts. EPSS probability is low (0.04%, 14th percentile) and no active exploitation is confirmed, but SSVC framework rates this as automatable with total technical impact. Vendor patch available in BC-JAVA 1.84.
Bouncy Castle for Java before 1.86 leaks secret-derived information from its HQC post-quantum KEM through two side channels, allowing a local attacker who can observe CPU cache behaviour or precisely measure decapsulation timing to recover information about the HQC private key. Only deployments that actually perform HQC encapsulation or decapsulation on the affected library are exposed, and exploitation requires either code co-resident on the same physical host or many carefully controlled timing measurements, so isolated single-tenant hardware largely neutralises the cache channel. There is no public exploit identified at time of analysis; this is a genuine cryptographic weakness but a comparatively low-urgency operational priority, and a vendor fix is available in version 1.86.
Key-size validation bypass in Bouncy Castle for Java before 1.86 (and Bouncy Castle for Java FIPS before bcpkix-fips 2.0.13 / 2.1.13) allows a key-transport EnvelopedData or AuthEnvelopedData message whose HKDF-derived content-encryption key does not match the advertised content-encryption algorithm to be accepted even when the application has explicitly enabled org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true). The defect is confined to messages using RFC 9709 CEK derivation (id-alg-cek-hkdf-sha256); messages with a matching key size, non-HKDF messages, and recipients that never enable validation are unaffected, and the opt-in control is off by default, so this is a medium-severity defense-in-depth failure rather than a direct decryption or key-recovery primitive. Unauthenticated remote attackers who can supply CMS content to an application that has enabled the control can silently defeat the only mechanism the API offers for enforcing recovered key size; no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor-released patch is available.
Denial of service in Bouncy Castle for Java (bc-java before 1.86 and bc-lts-java before 2.73.13) arises because the legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families derive keys using an iteration count read from untrusted input without upper or lower bounds, so a tiny amount of attacker-controlled data can force an unbounded amount of CPU work before any validation occurs. Unauthenticated remote attackers can trigger the condition by supplying crafted PKCS12PBEParams/PBEParameter encodings or a PKCS#12 PBE-protected private key that the application processes through the raw JCA provider, including the common javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() path; impact is availability-only (CPU/time exhaustion) with no confidentiality or integrity effect, and the assessed severity is moderate (CVSS 3.1 5.3, A:L). No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV) information for this issue.
Unbounded key-derivation cost parameters in Bouncy Castle for Java before 1.86 allow a denial of service against applications that parse attacker-influenced cryptographic structures: PBKDF2 iteration counts, derived-key lengths, scrypt parallelization factor p, and OpenSSH v1 bcrypt round counts were read straight from untrusted input and used to drive the KDF before any password or MAC verification could reject the data. Affected code paths include the RFC 9579 PBMAC1 MAC calculator builders (JcePBMac1CalculatorBuilder, PKCS12PBEUtils.createPBMac1Calculator reached via PKCS12PfxPdu.isMacValid), the PKCS#8/PKCS#12 scrypt cost guards, the raw JCA PBKDF2 provider, and OpenSSH v1 private-key parsing in Bouncy Castle for Java, LTS (before 2.73.13) and FIPS (bcpkix-fips before 1.0.13 / 2.0.13 / 2.1.13). Impact is availability-only (CVSS:4.0 5.3; assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L): exploitation requires the victim application to passively process a malicious blob and is unauthenticated (PR:N), but no key material or data is exposed, and there is no public exploit identified at time of analysis.
Unbounded PKCS#12 KDF iteration counts in Bouncy Castle for Java allow remote, unauthenticated attackers to cause denial of service by supplying a crafted PKCS#12 file with an arbitrarily large iteration count in MAC or bag-decryption KDF parameters. Any Java application that processes PKCS#12 keystores using bc-java before 1.85, bc-lts-java before 2.73.12, or bc-fja (FIPS) before 1.0.2.7/2.0.2/2.1.3 is affected. No public exploit is identified at time of analysis, but the attack surface is broad given how widely PKCS#12 files are accepted across Java enterprise stacks.
CPU and memory exhaustion in Bouncy Castle Java's BCFKS keystore loader exposes applications to pre-integrity-verification denial of service when processing a crafted keystore file. Any of the three affected library variants - bc-java (before 1.85), bc-lts-java (before 2.73.12), and BC-FJA (before 1.0.2.7, 2.0.2, or 2.1.3 depending on series) - will blindly honour attacker-supplied PBKDF2 iteration counts or scrypt cost parameters read from an untrusted file before the keystore MAC is verified, allowing an adversary to trigger arbitrary CPU or memory consumption at load time. No public exploit code has been identified and the vulnerability is absent from CISA KEV; urgency is rated Amber by the upstream reporter.
CPU-exhaustion denial of service in Bouncy Castle for Java affects any server that verifies CMP (Certificate Management Protocol) password-MAC protected messages using PKMACBuilder without an explicit iteration ceiling. The library's PKMACBuilder accepted the iteration count directly from the unauthenticated PBMParameter field in an incoming CMP message with no upper bound, allowing a remote unauthenticated attacker to supply a count near 2^31 and force billions of hash iterations on the target. No active exploitation is confirmed (not in CISA KEV), but the attack is unauthenticated, requires no special configuration beyond standard CMP usage, and a patch is available upstream.
Heap and CPU exhaustion in Bouncy Castle for Java's OpenPGP implementation allows remote unauthenticated attackers to cause denial of service by crafting OpenPGP messages with extreme Argon2 S2K cost parameters. The library honoured attacker-controlled memory, passes (iterations), and parallelism fields embedded in unauthenticated OpenPGP packets before any message authentication could occur, meaning a single crafted packet could instruct the JVM to allocate up to 2^30 KiB (approximately 1 TiB) of heap. No public exploit code or CISA KEV listing has been identified at time of analysis; however, the vulnerability is straightforward to exploit given that the cost parameters are trivially crafted and processed unconditionally.
LDAP filter injection in Bouncy Castle bc-java before 1.85 allows network-reachable attackers to manipulate LDAP directory search queries by supplying certificates with crafted Subject or Issuer CN values containing LDAP metacharacters. This is a bypass of the CVE-2023-33201 fix: the escaping was applied to the main-Java LDAPStoreHelper and both X509LDAPCertStoreSpi variants, but the jdk1.4 Ant build overlay carries its own private parseDN method that was never patched, leaving bcprov-jdk14 consumers exposed. No public exploit code has been identified and this vulnerability is not listed in CISA KEV at time of analysis.
Denial-of-service via unbounded KDF cost in Bouncy Castle for Java's PKCS#8 / PBES2 decryptors allows remote attackers to exhaust CPU or memory by supplying crafted encrypted key material with extreme KDF parameters. The vulnerability affects bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bcpkix-fips) across all supported 1.0.X, 2.0.X, and 2.1.X series. No public exploit has been identified at time of analysis, and active exploitation has not been confirmed by CISA KEV.
Out-of-bounds write in Bouncy Castle BC-LTS bcprov-lts8on affects ARM deployments running versions 2.73.0 through 2.73.12.0, with high confidentiality impact if successfully exploited. The flaw resides in ARM-specific native C implementations of SHA3 and SHAKE algorithms and is only triggered when an application accepts memoable SHA3/SHAKE cryptographic states from potentially untrusted external sources. No public exploit code exists and no active exploitation has been confirmed at time of analysis; the CVSS 4.0 score of 1.7 reflects the very narrow exploitation conditions required to reach this code path.
Availability degradation in Bouncy Castle BC-FJA cryptographic library versions 2.1.0 through 2.1.2 on Linux X86_64 systems with AVX or AVX-512f SIMD extensions affects GCM-128 and GCM-512 operations, allowing local attackers to cause denial of service without authentication. The vulnerability is associated with optimized assembly implementations (gcm128w, gcm512w) and results in availability impact with no confidentiality or integrity compromise. No public exploit code or active exploitation has been identified at time of analysis.
Signature verification bypass in Bouncy Castle BC-JAVA (bcpkix module versions 1.49-1.83) allows remote unauthenticated attackers to forge cryptographic signatures by submitting empty signature sequences that are incorrectly accepted as valid by the draft CompositeVerifier implementation. This critical flaw (CVSS 4.0: 10.0) enables complete subversion of digital signature trust chains, potentially allowing authentication bypass, code signing forgery, and man-in-the-middle attacks against Java ap
LDAP injection in Bouncy Castle BC-JAVA bcprov module (versions 1.49 through 1.83) allows remote unauthenticated attackers to manipulate LDAP queries via specially crafted input to LDAPStoreHelper.java, enabling complete compromise of confidentiality, integrity, and availability across security boundaries. This critical vulnerability (CVSS 10.0) affects a widely deployed cryptographic library used throughout the Java ecosystem. No active exploitation confirmed (not in CISA KEV), but the attack r
GOST CTR block cipher in Bouncy Castle BC-JAVA processes only the first 255 blocks correctly, causing silent data corruption in encryption/decryption operations for longer messages. Affects BC-JAVA versions 1.59 through 1.83, with fix available in version 1.84. Local attack vector (CVSS AV:L) with critical CVSS 9.4 score reflects potential for both confidentiality and integrity compromise when applications process GOST-encrypted data streams exceeding 255 blocks (~4KB). No KEV listing or public
Keystream reuse in the native one-shot CTR packet cipher of Bouncy Castle for Java LTS before 2.73.13 allows remote attackers to recover plaintext from ciphertext alone, without knowledge of the key. Exploitation is unauthenticated but conditional: the application must use the native one-shot CTR path with a 13-, 14-, or 15-byte IV, leaving only a 1-, 2-, or 3-byte block counter (256, 65,536, or 16,777,216 blocks), and must pass a single input longer than that counter space so the counter wraps and the keystream restarts within the packet. The call returns the full input length with no exception, so the caller receives no signal that some bytes were transformed under a repeated keystream; the resulting two-time-pad condition permits plaintext recovery. No public exploit code has been identified at time of analysis, and the non-default short-IV native deployment requirement keeps realistic exposure narrow, which is why this is assessed as AC:H rather than trivially exploitable.
Bouncy Castle for Java before 1.86 fails to tie a Remove proposal in an MLS (RFC 9420) external commit to the joining party, allowing any holder of the group's public GroupInfo to evict an arbitrary member and take over that member's slot in the ratchet tree. Exploitation requires only that an application use the library's MLS module and accept external commits through the public Group.externalJoin / Group.handle API on an affected version; no group membership, credential, or user interaction is needed, and the missing credential check existed only in the gRPC interop harness, protecting none of the other API callers. The vendor rates this 8.7 (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N), and there is no public exploit identified at time of analysis, though the flaw is trivially reachable by anyone who legitimately receives GroupInfo.
Signature-verification bypass in Bouncy Castle for Java before 1.86 lets a phantom signer be accepted in BLS12-381 aggregate signature verification. The faulty BLS12_381BasicScheme.keyValidate() trusts the public key's own ECCurve object during the prime-order subgroup check, so an attacker-supplied ECPoint built on a foreign curve that merely shares BLS12-381's field characteristic - with its cofactor forged to 1 - passes validation despite not being a G1 point; in the pairing implementation such a point contributes the identity in the target group, so an aggregate signature verifies even though it contains no signature for that key/message pair. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key, since the standard 48-byte compressed-point decoder always supplies the canonical curve; no public exploit has been identified at time of analysis, and the assessed impact is high integrity compromise without confidentiality or availability loss (CVSS:4.0 base 7.1, network vector, no privileges required).
Bouncy Castle for Java's Messaging Layer Security (MLS, RFC 9420) implementation before 1.86 fails to bind an X.509 credential to a LeafNode's signature_key, allowing an unauthenticated remote attacker to present a victim's certificate while signing the LeafNode and KeyPackage with an unrelated key and be accepted under the victim's identity. In an MLS deployment that uses X.509 credentials and admits external commits without an independent credential-admission check, the attacker can be admitted as the victim, evict the victim via resynchronization (which compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. The flaw is rated CVSS 9.2 (CVSS:4.0) / 9.2-equivalent high impact with the vendor patch available in 1.86; no public exploit code or confirmed active exploitation was identified at time of analysis, and deployments using only basic credentials are explicitly unaffected. Note the assessed attack complexity is High because the MLS/X.509 path must be in use and the application must lack its own credential-admission validation.
Bouncy Castle for Java 1.81 through 1.85.2 fails to verify that a third-party OpenPGP signature was issued by a component key actually granted certification authority, so the high-level certificate API will attribute an attacker-made certification or trust delegation to the certificate's offline primary key. An attacker must already hold the private key of a restricted subkey (one bound only with SIGN_DATA, or a legacy RSA encryption subkey whose algorithm can still sign) that lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER flag; they can then issue a positive User ID certification or a full-trust depth-one direct-key delegation that getCertificationBy()/getDelegationBy() report as a valid chain, and any application treating isValid() as an identity or trusted-introducer decision will accept the forged assertion at the primary key's authority. The flaw is a privilege promotion of an already-compromised subkey rather than a key-recovery attack, no public exploit code has been identified at time of analysis, and vendor fixes are available in 1.86.
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
In-place encryption over a secret key buffer in Bouncy Castle for Java LTS before 2.73.13 can silently replace freshly produced ciphertext with the raw AES key, because native one-shot packet ciphers release read-only input arrays with JNI mode 0 and a later copy-back overwrites the output. The trigger is narrow and application-dependent-it requires the non-default pattern of passing the same Java array as both input and destination (for example, encrypting over KeyParameter.getKey()) on a JVM that copies rather than pins JNI array elements-so real-world exploitability is far lower than the 8.2 base score implies; bcprov, pure-Java packet ciphers, and native streaming modes are unaffected. No public exploit identified at time of analysis.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Certificate-validation bypass in Bouncy Castle for Java lets a PKIXCertPathReviewer accept an end-entity certificate that violates a NameConstraints extension imposed by its own issuing CA, causing isValidCertPath() to return true with an empty error list for a chain the real PKIX validator rejects. Affected are BC-Java before 1.86, BC-LTS-Java before 2.73.13, and BC-FJA (bcpkix-fips) before 1.0.13 / 2.0.13 / 2.1.13; exploitation requires an application that uses org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer (or the legacy org.bouncycastle.x509 copy) to make the trust decision rather than the unaffected CertPathValidator "PKIX"/"BC", and a chain whose leaf actually breaches the CA's permitted or excluded subtrees. No public exploit code has been identified at time of analysis, the vulnerability is unauthenticated (CVSS PR:N) per the vendor vector, and the vendor scores it CVSS 4.0 8.7 (High) for high integrity impact; note that an independent assessment rates attack complexity higher (CVSS 3.1 AV:N/AC:H) because the exposure depends entirely on non-default application architecture rather than on anything the attacker controls.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Timing side-channel leakage in Bouncy Castle for Java (bc-java) versions before 1.86 exposes private-key information from NTRU post-quantum KEM operations because three modular-reduction helpers used the '%' operator, which compiles to an integer division whose latency depends on the secret operand. Affected call paths include key generation (secret polynomials f and g), encapsulation (message polynomials r and m), and decapsulation (coefficients recovered from the private key), and the CVSS 4.0 base score is 8.2 (assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - confidentiality only). Exploitation requires the application to actually invoke NTRU KEM operations with a persistent/reused key and an attacker able to repeatedly measure operation timing with low jitter, so practical risk is limited to deployments that use NTRU and expose those operations to a co-located or low-latency timing observer; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV listing), but a vendor patch is available and should be applied.
Heap-exhaustion denial of service in the MLS implementation of Bouncy Castle for Java (bc-java) before 1.86, triggered by a single small PrivateMessage whose SenderData carries a wire-encoded uint32 leaf_index with its top bit set. Because that value is held in a signed int, it decodes as negative and passes the signed bounds checks in GroupKeySet.SecretTree.hasLeaf and Group.validateRemove, letting a sender outside the tree reach LeafIndex.directPath()/NodeIndex.parent() arithmetic that never terminates at the tree root and grows a node list until the JVM runs out of heap. Impact is confined to availability (CVSS 4.0 8.7 with VA:H and no confidentiality or integrity effect); group membership is a practical prerequisite since the triggering MLS message or Remove proposal must originate from a current group participant, and applications that do not use org.bouncycastle.mls are unaffected. No public exploit code identified at time of analysis and the issue is not in CISA KEV; the vendor has released a fix in Bouncy Castle 1.86.
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.
Cryptographic key material in Bouncy Castle for Java FIPS (BC-FJA) persists in the JVM heap far beyond its intended lifetime on Java 12 and later runtimes because the library's zeroisation scheme relies on Object.finalize(), a mechanism progressively de-emphasized since Java 9 and deprecated for removal in Java 18. Under load, the single finalizer thread cannot retire pending objects as fast as they are allocated, causing the queue to grow without bound - resulting in an OutOfMemoryError that crashes the application and defeating the cryptographic hygiene goal of prompt key zeroisation. No public exploit is identified at time of analysis; however, any network-accessible application built on BC-FJA prior to the fixed versions is exposed to both a remotely triggerable denial-of-service and prolonged in-memory residence of sensitive key material.
Unbounded retry loops in BC-FJA's JNI native entropy layer cause calling threads to hang indefinitely when Intel RDSEED or RDRAND instructions persistently fail, producing a non-interruptible thread-level denial of service in any Java FIPS application backed by bc-fips 2.1.x before 2.1.3. The affected JNI seeding routine re-issues the CPU entropy instruction without any iteration limit whenever the carry flag signals failure - a condition reproducible by hardware entropy source faults, DRBG exhaustion under heavy multi-core contention, or hypervisors that do not forward these Intel instructions to guest VMs. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the conditions are routinely present in virtualized environments where hypervisors commonly withhold RDRAND/RDSEED forwarding, making this a realistic operational risk for enterprise Java FIPS deployments in cloud or VM-based infrastructure.
Uncontrolled recursion in Bouncy Castle for Java's lazy ASN.1 parser enables remote unauthenticated denial of service across all three library release lines (bc-java, bc-lts-java, and bc-fja FIPS). When a LazyEncodedSequence is forced during tree traversal, it resets the nesting-depth guard to its configured maximum instead of continuing with the remaining depth budget, allowing crafted deeply-nested ASN.1 structures to bypass StreamUtil's recursion limit and trigger a StackOverflowError. No public exploit has been identified at time of analysis, but any Java application accepting externally-supplied ASN.1 data - TLS certificates, CMS signatures, PKCS structures - is potentially exposed without authentication.
RSA PKCS#1 v1.5 signature forgery is possible in Bouncy Castle for Java (bc-java before 1.85, bc-lts-java before 2.73.12) when the DigestInfo encoding omits the NULL AlgorithmIdentifier parameter. The off-by-two bytes in the RSADigestSigner comparison loop allows any forged signature whose DigestInfo matches all bytes except the final two of the message hash to pass verification as valid, achieving a high-integrity bypass. No public exploit has been identified at time of analysis, but the public patch commit includes a step-by-step test demonstrating the exact forgery technique, substantially lowering the bar to exploitation.
Heap exhaustion via uncontrolled memory allocation in Bouncy Castle for Java's MLS wire decoder allows remote unauthenticated attackers to crash any application using the bc-java MLS module. The MLSInputStream.readOpaque() method decodes an attacker-supplied Varint length field (up to 0x3FFFFFFF, approximately 1 GiB) and allocates that buffer before verifying the input stream actually contains that many bytes; a handful of concurrent few-byte crafted messages can exhaust the JVM heap. No public exploit has been identified at time of analysis and CISA KEV listing is absent, though the attack is trivially constructable from the published patch and regression test.
OpenPGP AEAD decryption in Bouncy Castle for Java silently bypasses the final authentication tag when plaintext is an exact multiple of the AEAD chunk length, allowing an attacker who can tamper with ciphertext to strip trailing plaintext chunks and have the truncated message accepted as cryptographically authentic. Affected libraries span bc-java before 1.85, bc-lts-java before 2.73.12, and all three active BC-FJA FIPS series before their respective bcpg-fips 1.0.13, 2.0.13, and 2.1.13 releases. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the CVSS 4.0 score of 8.7 (Integrity: High) reflects a complete and silent bypass of AEAD integrity guarantees for chunk-aligned messages with no downstream exception or warning.
IESEngine in Bouncy Castle for Java allows cross-message MAC forgery when stream mode is used with static key pairs, affecting bc-java before 1.85 and bc-lts-java before 2.73.12. The flaw stems from a length-dependent KDF output split: in the static-key path (no ephemeral V component), the MAC key K2 was placed at a byte offset equal to the message length after the keystream K1, so an observer of one known-plaintext encryption can recover K2 and forge valid ciphertext-plus-tag pairs for shorter messages. No public exploit beyond the vendor's own proof-of-concept regression test exists, and no CISA KEV listing is present at time of analysis.
Cross-nonce AEAD forgery in Bouncy Castle for Java's KCCMBlockCipher (DSTU 7624 CCM mode) allows an attacker with chosen-plaintext oracle access to forge valid authenticated ciphertext under an un-queried nonce when no associated authenticated data is present. All bc-java releases before 1.85 and bc-lts-java releases before 2.73.12 are affected. The G1 initialization block - which binds the nonce into the MAC under the DSTU 7624:2014 standard - was conditionally skipped when no AAD bytes were supplied, leaving the authentication tag independent of the nonce and breaking the core AEAD security guarantee. No public exploit has been independently released and this vulnerability is not listed in CISA KEV, though the fix commits include a working regression test that fully demonstrates the forgery technique.
CMS AuthEnvelopedData decryption in Bouncy Castle for Java fails to enforce a minimum AEAD authentication tag length, allowing a network attacker to supply a crafted CMS message carrying a truncated AES-GCM/CCM ICV (e.g., 32 bits instead of the standard 128 bits), effectively reducing the authentication space to the point where tag forgery becomes computationally feasible. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and all bc-fja (FIPS) 1.0.x/2.0.x/2.1.x series before their respective .12 patch releases. No public exploit or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.7 with VI:H reflects the high integrity impact of bypassing authenticated encryption guarantees.
Out-of-memory denial-of-service in Bouncy Castle for Java allows remote unauthenticated attackers to crash Java applications by submitting a crafted ASN.1 definite-length object with an inflated declared size. The ASN.1 parser in `DefiniteLengthInputStream.toByteArray()` allocated a full heap-sized byte array before reading any body bytes, meaning a few-byte header claiming a near-JVM-heap payload was sufficient to trigger OOM. All major Bouncy Castle release lines are affected - including the FIPS-certified BC-FJA variant - and a vendor patch is available; no public exploit code or CISA KEV listing exists at time of analysis.
CPU exhaustion in Bouncy Castle for Java allows remote attackers to cause denial of service by supplying X.500 distinguished name attribute values densely packed with RFC 4514 special characters or leading/trailing spaces. The root cause is a quadratic-time O(n²) escaping algorithm in `IETFUtils.valueToString()` that inserts backslashes into the buffer being actively scanned - triggerable through `X500Name.toString()`, `.equals()`, or `.hashCode()`, methods commonly invoked during TLS certificate and LDAP DN processing. No public exploit has been identified beyond the vendor's own regression test, and this vulnerability is not listed in CISA KEV, though the CVSS 4.0 score of 8.7 with AV:N/PR:N signals meaningful exposure for Internet-facing Java services.
Uncontrolled memory allocation in Bouncy Castle for Java's HSS public-key parser allows remote unauthenticated attackers to exhaust JVM heap memory by supplying a crafted public key with an arbitrarily large HSS level count (L value), causing denial of service during signature verification. All three product lines are affected: bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FIPS (bc-fja) before 2.0.2/2.1.3 depending on series. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the AV:N/AC:L/PR:N attack profile and Bouncy Castle's ubiquity as a Java crypto dependency make this a credible availability risk for any service accepting external HSS/LMS key material.
CCMBlockCipher in Bouncy Castle for Java decrypts ciphertext directly into the caller-supplied output buffer before verifying the authentication tag, leaving unverified CTR-decrypted plaintext in memory when tag verification fails and violating NIST SP 800-38C §6.2. Every edition - bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA across three active release lines (1.0.x, 2.0.x, 2.1.x) - is affected. Applications that reuse pooled byte buffers, log failure-path output, or otherwise expose the buffer on an authentication failure inadvertently become CTR decryption oracles, allowing attackers to submit forged ciphertexts and recover plaintext without possessing a valid authentication tag. No public exploit and no CISA KEV listing exist at time of analysis.
Certificate revocation-check bypass in the Bouncy Castle for Java (bc-java) PKIX provider allows a validly-signed OCSP response issued for one certificate to be accepted as proof-of-status for a different certificate, because the stapled response is not bound to the CertID of the certificate actually being checked. This means a revoked end-entity certificate can pass PKIXRevocationChecker validation when a 'good' OCSP response for another serial (e.g. the CA's) is supplied, defeating revocation enforcement in TLS/PKI clients that rely on OCSP stapling. Affected releases are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (FIPS) before 2.0.2 and 2.1.3; no public exploit identified at time of analysis and it is not listed in CISA KEV.
TLS hostname-verification bypass in the Bouncy Castle for Java JSSE provider (BCJSSE) ships the legacy certificate-CN fallback enabled by default, even though the vendor documentation states it is opt-in and gated behind the org.bouncycastle.jsse.client.checkCnFallback property. Affected are BC-Java before 1.85, BC-LTS before 2.73.12, and BC-FJA (FIPS) TLS module bctls-fips before 1.0.24, 2.0.24 and 2.1.24; a MITM-positioned attacker can present a SAN-less certificate whose Subject CN names the victim host and have it silently accepted, defeating name-constraint protections and enabling interception of TLS traffic (CWE-297). This carries a CVSS 4.0 base of 9.3, but there is no public exploit identified at time of analysis and it is not in CISA KEV.
Signature bypass in Bouncy Castle for Java allows any attacker-supplied content wrapped in a zero-signer CMS envelope to pass `CMSSignedData.verifySignatures()` without any valid cryptographic signature. The method iterates an empty signerInfos SET, falls through to a vacuous `return true`, and any application using it as its top-level authenticity check silently accepts unsigned attacker-controlled content as authenticated - a classic fail-open flaw (CWE-347). No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the attack primitive is trivially constructible using any standard CMS/PKCS#7 library.
Bouncy Castle for Java's OpenPGP session-key decryption path re-exposes the Mister-Zuccherato adaptive-chosen-ciphertext oracle by failing to suppress the legacy CFB 'quick check' on the PKESK/session-key route, enabling an attacker with decryption oracle access to recover plaintext from SEIPD v1 encrypted messages. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bcpg-fips) across the 1.0.X, 2.0.X, and 2.1.X series - three distinct product lines used broadly in enterprise and open-source Java applications. No public exploit or CISA KEV listing has been identified at time of analysis; however, the attack technique is well-established in cryptographic literature dating to the Mister-Zuccherato paper.
Signature forgery via back-dated signingTime in Bouncy Castle's S/MIME validator allows an attacker holding a revoked or expired signing certificate to have that certificate accepted as valid by unpatched validators. The SignedMailValidator in bc-java before 1.85, bc-lts-java before 2.73.12, and all bc-fja (FIPS) lines before their respective 1.0.7/2.0.7/2.1.7 fixes unconditionally used the signer-asserted CMS signingTime attribute as the PKIX path-validation date, making certificate expiry and revocation checks bypassable. No public exploit or CISA KEV listing exists at time of analysis, but the flaw is architecturally straightforward to exploit by any party that holds or has previously held a Bouncy Castle-validated signing certificate.
CMS AuthenticatedData integrity verification in Bouncy Castle for Java is bypassable when authenticated attributes (authAttrs) are present, allowing an attacker to substitute arbitrary content while the recipient MAC check passes without error. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA across the 1.0.x, 2.0.x, and 2.1.x series - all widely deployed in Java enterprise and FIPS environments. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VI:H) reflects unauthenticated remote exploitation with high integrity impact; no public exploit or CISA KEV listing is confirmed at time of analysis.
OpenPGP inline-signature policy enforcement in Bouncy Castle for Java silently discards rejection exceptions, causing signatures that use prohibited weak hash algorithms (MD5, SHA-1, RIPEMD-160) or otherwise violate the configured OpenPGPPolicy to be reported as cryptographically valid. Affected are bc-java before 1.85 and bcpg-fips (bc-fja) before 2.0.13; the detached-signature and prefixed-signature verification paths are not affected - only the inline one-pass path. A vendor patch is available; no public exploit code has been identified at time of analysis, though the CVSS 4.0 score of 8.7 reflects a high integrity impact driven by the unauthenticated network vector.
CPU exhaustion in Bouncy Castle for Java's MLS (Messaging Layer Security) implementation allows a network attacker to trigger unbounded HKDF key-derivation iterations by supplying a crafted 32-bit generation counter in an MLS message. The hash-ratchet in GroupKeySet.get(int generation) advances one HKDF step per skipped generation without any upper bound, so a maximally crafted counter forces up to ~4.29 billion derivation steps on the receiving process. Scored CVSS 4.0 at 8.7 with High availability impact and no authentication prerequisites per vendor scoring; no public exploit code or KEV listing has been identified at time of analysis.
Unbounded recursion in Bouncy Castle's OER (Octet Encoding Rules) parser enables remote unauthenticated denial-of-service against any Java application processing IEEE 1609.2 V2X messages. Because the IEEE 1609.2 schema is cyclic - an Ieee1609Dot2Data structure can nest inside its own SignedData payload - a few kilobytes of crafted input drive the parser into unbounded recursive descent, terminating in a JVM StackOverflowError. Critically, parsing occurs before signature verification, so no authentication or trust relationship is needed to trigger the crash. No public exploit has been identified at time of analysis, but the patch commit exposes two additional heap-exhaustion vectors alongside the primary recursion flaw, all reachable from the same pre-verification code path.
Memory exhaustion denial-of-service in Bouncy Castle's DTLS implementation allows remote unauthenticated attackers to crash or degrade Java applications by sending crafted handshake messages with inflated 24-bit length fields. Affected are bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bctls-fips) before 1.0.24, 2.0.24, or 2.1.24 depending on the deployed branch. The buffer allocation occurs pre-authentication during the DTLS handshake reassembly phase - before any signature or Finished verification - making this exploitable without credentials against any exposed DTLS endpoint. No public exploit code has been identified and the vulnerability is not listed in CISA KEV.
Memory exhaustion in Bouncy Castle for Java's OpenPGP parser enables unauthenticated remote denial of service via a crafted User Attribute subpacket with an oversized length header. All Java applications importing untrusted OpenPGP certificates using bc-java before 1.85, bc-lts-java before 2.73.12, or BC-FJA (FIPS) in affected series are vulnerable to pre-authentication JVM heap exhaustion. No KEV listing or public exploit has been confirmed at time of analysis, but the zero-complexity unauthenticated network attack vector and CVSS 4.0 score of 8.7 signal high operational priority for services that accept OpenPGP certificates from external sources.
Private key recovery in Bouncy Castle for Java (bc-java before 1.85, bc-lts-java before 2.73.12) affects the DH agreement code path, where a peer-supplied public value is exponentiated with the local private key without full range/subgroup validation. A malicious protocol peer can submit small-order or out-of-range Diffie-Hellman elements to mount a small-subgroup confinement attack and, when the local private key is static/reused, gradually recover it via CRT - enabling decryption and impersonation. No public exploit identified at time of analysis; the fix is a vendor-released patch and the vulnerability is not listed in CISA KEV.
Bouncy Castle for Java's BKS keystore implementation silently accepted legacy version 0/1 keystores that derive a critically weak 16-bit HMAC integrity key - brute-forceable offline in milliseconds against the 65,536-value keyspace - allowing an attacker who can supply or tamper with a keystore file to forge the integrity MAC, inject rogue trusted certificates, and have the manipulated keystore accepted without error. All bc-java releases before 1.85 and bc-lts-java releases before 2.73.12 are affected. No public exploit code has been identified and this vulnerability does not appear in the CISA KEV catalog at time of analysis.
Bouncy Castle for Java's BKS and UBER keystore implementation crashes with an OutOfMemoryError when loading a crafted keystore because heap allocation from stream-declared lengths occurs before the HMAC integrity check. Any application calling KeyStore.load() with attacker-controlled BKS or UBER keystore data is affected - bc-java before 1.85 and bc-lts-java before 2.73.12. A POC was submitted alongside the report, confirming that a file of just a few dozen bytes declaring Integer.MAX_VALUE-length fields is sufficient to exhaust JVM heap regardless of heap configuration or supplied password. No public exploit identified at time of analysis beyond the researcher's POC referenced in the patch commit.
Certificate name-constraint bypass in Bouncy Castle for Java allows a crafted certificate to escape X.509 permitted/excluded subtree restrictions by appending a trailing dot to an rfc822Name (email) or URI host, or by prepending RDNs ahead of a permitted directoryName. Any relying party using BC's PKIXNameConstraintValidator (via CertPathValidator/CertPathBuilder) to enforce name constraints can be tricked into trusting an identity a constrained CA was never authorized to issue, enabling impersonation and effective authentication bypass. There is no public exploit identified at time of analysis, but the vendor rates it 9.3 (Critical) and a fix is available.
Pre-authentication resource exhaustion in Bouncy Castle BC-JAVA PGP modules (bcpg) allows remote attackers to trigger denial-of-service by exploiting unbounded AEAD chunk sizes, affecting all versions before 1.84. The maximum CVSS 4.0 score of 10.0 reflects complete compromise potential across confidentiality, integrity, and availability with no attack complexity, no authentication requirements, and network-based exploitation. No public exploit identified at time of analysis, though the attack s
Non-constant time comparison operations in the Legion of the Bouncy Castle BC-JAVA cryptographic library (core modules, versions 2.17.3 through 1.83) expose FrodoKEM private keys to timing side-channel attacks, enabling remote unauthenticated attackers to extract cryptographic secrets through statistical analysis of operation timing variations. CVSS 4.0 score of 10.0 reflects maximum confidentiality and integrity impact across system and subsequent contexts. EPSS probability is low (0.04%, 14th percentile) and no active exploitation is confirmed, but SSVC framework rates this as automatable with total technical impact. Vendor patch available in BC-JAVA 1.84.
Bouncy Castle for Java before 1.86 leaks secret-derived information from its HQC post-quantum KEM through two side channels, allowing a local attacker who can observe CPU cache behaviour or precisely measure decapsulation timing to recover information about the HQC private key. Only deployments that actually perform HQC encapsulation or decapsulation on the affected library are exposed, and exploitation requires either code co-resident on the same physical host or many carefully controlled timing measurements, so isolated single-tenant hardware largely neutralises the cache channel. There is no public exploit identified at time of analysis; this is a genuine cryptographic weakness but a comparatively low-urgency operational priority, and a vendor fix is available in version 1.86.
Key-size validation bypass in Bouncy Castle for Java before 1.86 (and Bouncy Castle for Java FIPS before bcpkix-fips 2.0.13 / 2.1.13) allows a key-transport EnvelopedData or AuthEnvelopedData message whose HKDF-derived content-encryption key does not match the advertised content-encryption algorithm to be accepted even when the application has explicitly enabled org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true). The defect is confined to messages using RFC 9709 CEK derivation (id-alg-cek-hkdf-sha256); messages with a matching key size, non-HKDF messages, and recipients that never enable validation are unaffected, and the opt-in control is off by default, so this is a medium-severity defense-in-depth failure rather than a direct decryption or key-recovery primitive. Unauthenticated remote attackers who can supply CMS content to an application that has enabled the control can silently defeat the only mechanism the API offers for enforcing recovered key size; no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor-released patch is available.
Denial of service in Bouncy Castle for Java (bc-java before 1.86 and bc-lts-java before 2.73.13) arises because the legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families derive keys using an iteration count read from untrusted input without upper or lower bounds, so a tiny amount of attacker-controlled data can force an unbounded amount of CPU work before any validation occurs. Unauthenticated remote attackers can trigger the condition by supplying crafted PKCS12PBEParams/PBEParameter encodings or a PKCS#12 PBE-protected private key that the application processes through the raw JCA provider, including the common javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() path; impact is availability-only (CPU/time exhaustion) with no confidentiality or integrity effect, and the assessed severity is moderate (CVSS 3.1 5.3, A:L). No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV) information for this issue.
Unbounded key-derivation cost parameters in Bouncy Castle for Java before 1.86 allow a denial of service against applications that parse attacker-influenced cryptographic structures: PBKDF2 iteration counts, derived-key lengths, scrypt parallelization factor p, and OpenSSH v1 bcrypt round counts were read straight from untrusted input and used to drive the KDF before any password or MAC verification could reject the data. Affected code paths include the RFC 9579 PBMAC1 MAC calculator builders (JcePBMac1CalculatorBuilder, PKCS12PBEUtils.createPBMac1Calculator reached via PKCS12PfxPdu.isMacValid), the PKCS#8/PKCS#12 scrypt cost guards, the raw JCA PBKDF2 provider, and OpenSSH v1 private-key parsing in Bouncy Castle for Java, LTS (before 2.73.13) and FIPS (bcpkix-fips before 1.0.13 / 2.0.13 / 2.1.13). Impact is availability-only (CVSS:4.0 5.3; assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L): exploitation requires the victim application to passively process a malicious blob and is unauthenticated (PR:N), but no key material or data is exposed, and there is no public exploit identified at time of analysis.
Unbounded PKCS#12 KDF iteration counts in Bouncy Castle for Java allow remote, unauthenticated attackers to cause denial of service by supplying a crafted PKCS#12 file with an arbitrarily large iteration count in MAC or bag-decryption KDF parameters. Any Java application that processes PKCS#12 keystores using bc-java before 1.85, bc-lts-java before 2.73.12, or bc-fja (FIPS) before 1.0.2.7/2.0.2/2.1.3 is affected. No public exploit is identified at time of analysis, but the attack surface is broad given how widely PKCS#12 files are accepted across Java enterprise stacks.
CPU and memory exhaustion in Bouncy Castle Java's BCFKS keystore loader exposes applications to pre-integrity-verification denial of service when processing a crafted keystore file. Any of the three affected library variants - bc-java (before 1.85), bc-lts-java (before 2.73.12), and BC-FJA (before 1.0.2.7, 2.0.2, or 2.1.3 depending on series) - will blindly honour attacker-supplied PBKDF2 iteration counts or scrypt cost parameters read from an untrusted file before the keystore MAC is verified, allowing an adversary to trigger arbitrary CPU or memory consumption at load time. No public exploit code has been identified and the vulnerability is absent from CISA KEV; urgency is rated Amber by the upstream reporter.
CPU-exhaustion denial of service in Bouncy Castle for Java affects any server that verifies CMP (Certificate Management Protocol) password-MAC protected messages using PKMACBuilder without an explicit iteration ceiling. The library's PKMACBuilder accepted the iteration count directly from the unauthenticated PBMParameter field in an incoming CMP message with no upper bound, allowing a remote unauthenticated attacker to supply a count near 2^31 and force billions of hash iterations on the target. No active exploitation is confirmed (not in CISA KEV), but the attack is unauthenticated, requires no special configuration beyond standard CMP usage, and a patch is available upstream.
Heap and CPU exhaustion in Bouncy Castle for Java's OpenPGP implementation allows remote unauthenticated attackers to cause denial of service by crafting OpenPGP messages with extreme Argon2 S2K cost parameters. The library honoured attacker-controlled memory, passes (iterations), and parallelism fields embedded in unauthenticated OpenPGP packets before any message authentication could occur, meaning a single crafted packet could instruct the JVM to allocate up to 2^30 KiB (approximately 1 TiB) of heap. No public exploit code or CISA KEV listing has been identified at time of analysis; however, the vulnerability is straightforward to exploit given that the cost parameters are trivially crafted and processed unconditionally.
LDAP filter injection in Bouncy Castle bc-java before 1.85 allows network-reachable attackers to manipulate LDAP directory search queries by supplying certificates with crafted Subject or Issuer CN values containing LDAP metacharacters. This is a bypass of the CVE-2023-33201 fix: the escaping was applied to the main-Java LDAPStoreHelper and both X509LDAPCertStoreSpi variants, but the jdk1.4 Ant build overlay carries its own private parseDN method that was never patched, leaving bcprov-jdk14 consumers exposed. No public exploit code has been identified and this vulnerability is not listed in CISA KEV at time of analysis.
Denial-of-service via unbounded KDF cost in Bouncy Castle for Java's PKCS#8 / PBES2 decryptors allows remote attackers to exhaust CPU or memory by supplying crafted encrypted key material with extreme KDF parameters. The vulnerability affects bc-java before 1.85, bc-lts-java before 2.73.12, and BC-FJA (bcpkix-fips) across all supported 1.0.X, 2.0.X, and 2.1.X series. No public exploit has been identified at time of analysis, and active exploitation has not been confirmed by CISA KEV.
Out-of-bounds write in Bouncy Castle BC-LTS bcprov-lts8on affects ARM deployments running versions 2.73.0 through 2.73.12.0, with high confidentiality impact if successfully exploited. The flaw resides in ARM-specific native C implementations of SHA3 and SHAKE algorithms and is only triggered when an application accepts memoable SHA3/SHAKE cryptographic states from potentially untrusted external sources. No public exploit code exists and no active exploitation has been confirmed at time of analysis; the CVSS 4.0 score of 1.7 reflects the very narrow exploitation conditions required to reach this code path.
Availability degradation in Bouncy Castle BC-FJA cryptographic library versions 2.1.0 through 2.1.2 on Linux X86_64 systems with AVX or AVX-512f SIMD extensions affects GCM-128 and GCM-512 operations, allowing local attackers to cause denial of service without authentication. The vulnerability is associated with optimized assembly implementations (gcm128w, gcm512w) and results in availability impact with no confidentiality or integrity compromise. No public exploit code or active exploitation has been identified at time of analysis.
Signature verification bypass in Bouncy Castle BC-JAVA (bcpkix module versions 1.49-1.83) allows remote unauthenticated attackers to forge cryptographic signatures by submitting empty signature sequences that are incorrectly accepted as valid by the draft CompositeVerifier implementation. This critical flaw (CVSS 4.0: 10.0) enables complete subversion of digital signature trust chains, potentially allowing authentication bypass, code signing forgery, and man-in-the-middle attacks against Java ap
LDAP injection in Bouncy Castle BC-JAVA bcprov module (versions 1.49 through 1.83) allows remote unauthenticated attackers to manipulate LDAP queries via specially crafted input to LDAPStoreHelper.java, enabling complete compromise of confidentiality, integrity, and availability across security boundaries. This critical vulnerability (CVSS 10.0) affects a widely deployed cryptographic library used throughout the Java ecosystem. No active exploitation confirmed (not in CISA KEV), but the attack r
GOST CTR block cipher in Bouncy Castle BC-JAVA processes only the first 255 blocks correctly, causing silent data corruption in encryption/decryption operations for longer messages. Affects BC-JAVA versions 1.59 through 1.83, with fix available in version 1.84. Local attack vector (CVSS AV:L) with critical CVSS 9.4 score reflects potential for both confidentiality and integrity compromise when applications process GOST-encrypted data streams exceeding 255 blocks (~4KB). No KEV listing or public