Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not.
Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has observed one encrypted message with known plaintext to forge shorter messages of their choosing that the recipient accepts as authentic, via a crafted ciphertext and MAC tag, because the MAC key was taken from the key derivation output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. The keystream revealed by that one message therefore contains the MAC key for every sufficiently shorter message.
Missing cryptographic step in the DSTU 7624 CCM mode implementation (KCcmBlockCipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can observe encrypted messages of known or chosen content to forge ciphertexts with valid authentication tags, via messages encrypted without associated data. The cause is that the G1 block, which binds the nonce, the message length and the parameter flags into the CBC-MAC, was processed only when associated data was present. Without associated data the tag was a CBC-MAC of the plaintext alone, independent of the nonce. Only applications that use KCcmBlockCipher directly and supply no associated data are affected.
Improper validation of integrity check value in the AES-CCM implementation (CcmParameters and CcmBlockCipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an on-path attacker to modify CCM-encrypted content without detection via an AlgorithmIdentifier whose CCMParameters declare an authentication tag (aes-ICVlen) of zero or another length outside the RFC 5084 set, because CcmParameters accepted any value and CcmBlockCipher validated the tag length only when encrypting, so decryption compared a zero-length or very short tag. Affected paths include ParameterUtilities.GetCipherParameters, used by CmsEnvelopedData and CmsEnvelopedDataParser for EnvelopedData encrypted with AES-CCM, and any caller passing an unchecked tag length to CcmBlockCipher for decryption.
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was zeroised on garbage collection by overriding Object.finalize. Finalization runs at an unspecified time and in an unspecified order and is serviced by a single finalizer thread, so where objects carrying a finalizer are allocated faster than that thread retires them the pending-finalization queue grows without bound: disposal falls arbitrarily far behind, which can contribute to an OutOfMemoryError under load, and the key material those objects hold stays resident in the heap for as long as they are queued, defeating the purpose of the zeroisation. The behaviour was not a problem on Java 8 or Java 11; it is later JVMs, on which finalization has been deprecated and progressively de-emphasised, where it becomes one. Disposal of these classes now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later it no longer depends on the finalizer being scheduled. Bouncy Castle for Java (bcprov) and Bouncy Castle for Java LTS are not affected, as neither implements the finalizer-based zeroisation scheme.
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store. Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X FIPS series are not affected.
CVE-2026-12185 is a high severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. It involves memory allocation with excessive size values in BKS/UBER keystore implementations before integrity checks are performed. This affects versions prior to 1.85 and versions from 2.73.0 up to but not including 2.73.12.
CVE-2026-13506 is a high severity vulnerability in Bouncy Castle for Java (BC-JAVA) involving uncontrolled recursion due to a Lazy ASN.1 sequence forcing that resets the nesting-depth guard. This affects versions before 1.85 and certain LTS and FIPS versions prior to specified fixed releases. The vulnerability has a CVSS 4.0 score of 8.7, indicating a significant impact if exploited. No official patch or remediation level is currently confirmed from the vendor advisory. No known exploits are reported in the wild.
CVE-2026-12802 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. It involves improper validation of the integrity check value in the CMS AuthEnvelopedData decryption process, specifically failing to enforce tag-length. This affects versions of Bouncy Castle for Java before 1.85 and certain LTS and FIPS versions prior to specified patch releases.
CVE-2026-59638 is a critical vulnerability in Bouncy Castle for Java where the JSSE hostname verifier CN-fallback is enabled by default despite being documented as opt-in. This affects versions before 1.85, including LTS versions before 2.73.12 and FIPS versions before specified patch releases. The flaw involves improper validation of certificates with host mismatches, categorized under CWE-297.
CVE-2026-59639 is a high severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. The issue occurs in versions before 1.85 and certain 2.73.x versions, where the CMS verifySignatures method incorrectly returns true for SignedData objects that have zero signers. This improper verification of cryptographic signatures can undermine the trustworthiness of signature validation in affected versions.
CVE-2026-59640 is a high-severity vulnerability in Bouncy Castle for Java (BC-JAVA) involving an OpenPGP CFB quick-check oracle on symmetric/session-key paths. This affects versions before 1.85, versions from 2.73.0 up to but not including 2.73.12, and certain FIPS series versions. The vulnerability is categorized under CWE-203 (Observable Discrepancy). No official patch or remediation level has been confirmed yet.
CVE-2026-59641 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. The issue involves insufficient verification of data authenticity in the S/MIME validator, which trusts the signer-asserted signingTime during path validation. This affects versions of BC-JAVA before 1.85 and versions from 2.73.0 up to but not including 2.73.12, including certain FIPS variants. The vulnerability has a CVSS 4.0 score of 8.7, indicating a significant security risk. No official patch or remediation level has been confirmed yet. There are no known exploits in the wild at this time.
CVE-2026-59642 is a high-severity vulnerability in Bouncy Castle for Java (BC-JAVA) affecting versions before 1.85 and certain LTS and FIPS versions prior to specified patch releases. The issue involves improper validation of the integrity check value in CMS AuthenticatedData when authenticated attributes are present, meaning the content is not properly bound to the MAC. This could undermine the integrity guarantees of the cryptographic message syntax implementation.
CVE-2026-59643 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library affecting versions 1.81 through before 1.85. The issue involves improper verification of cryptographic signatures, specifically OpenPGP inline-signature policy failures that are silently ignored. This flaw also impacts the Bouncy Castle for Java FIPS (BC-FJA) before version bcpg-fips 2.0.13. The vulnerability could allow attackers to bypass signature verification checks, undermining cryptographic assurances.
CVE-2026-59644 is a high-severity vulnerability in Bouncy Castle for Java (BC-JAVA) versions before 1.85. It involves the MLS hash-ratchet honoring an arbitrary 32-bit generation counter from the sender, leading to excessive iteration. This flaw is categorized under CWE-834 (Excessive Iteration).
CVE-2026-59645 is a high-severity vulnerability in Bouncy Castle for Java (BC-JAVA) affecting versions before 1.85 and certain LTS and FIPS versions. The issue involves the OER parser performing uncontrolled recursion without a depth limit on a self-referential IEEE 1609.2 schema, potentially leading to resource exhaustion or denial of service.
A high-severity vulnerability (CVE-2026-59646) exists in Bouncy Castle for Java (BC-JAVA) where the DTLS handshake reassembler allocates a buffer based on an unchecked 24-bit length value. This affects versions before 1.85 and versions from 2.73.0 up to but not including 2.73.12, including certain FIPS series releases. The unchecked allocation can lead to excessive memory allocation, classified under CWE-789.
CVE-2026-59647 is a medium severity vulnerability in Bouncy Castle for Java where the CRMF/CMP password-MAC implementation honors an unbounded iteration count. This affects versions before 1.85, and versions from 2.73.0 up to but not including 2.73.12. The issue relates to allocation of resources without limits or throttling, potentially leading to resource exhaustion.