In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged.
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
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-59650 is a critical vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library affecting versions before 1.85 and LTS versions from 2.73.0 up to but not including 2.73.12. The flaw involves improper input validation in the MTI/A0 Diffie-Hellman agreement process, where an unvalidated peer value is exponentiated. This can lead to severe cryptographic failures. The vulnerability has a high CVSS 4.0 score of 9.3, indicating network exploitable with no privileges or user interaction required. No official patch or remediation guidance is currently confirmed from the vendor advisory. There are no known exploits in the wild at this time.
CVE-2026-59651 is a vulnerability in Bouncy Castle for Java (BC-JAVA) affecting versions before 1.85 and LTS versions from 2.73.0 up to but not including 2.73.12. The issue involves the BKS keystore accepting a legacy version that uses a 16-bit integrity MAC key, which is considered inadequate encryption strength. This weakness could potentially undermine the integrity protection of the keystore data.
CVE-2026-59652 is an LDAP injection vulnerability in the Bouncy Castle for Java library (BC-JAVA) affecting versions before 1.85. The issue occurs in the legacy jdk1.4 LDAPStoreHelper component, where improper neutralization of special elements in LDAP queries allows injection. This vulnerability has a medium severity with a CVSS score of 6.9.
In Bouncy Castle for Java from 1.73 to before 1.78, three ML-KEM (CRYSTALS-Kyber) routines divided secret-derived polynomial coefficients by the modulus q: Poly.toMsg, which decodes the decrypted message, and the ciphertext compression routines Poly.compressPoly and PolyVec.compressPolyVec. An attacker able to measure the timing of a large number of decapsulations performed with the same long-term private key can recover that key. These are the KyberSlash1 (Poly.toMsg) and KyberSlash2 (ciphertext compression) divisions. Compression performed during encapsulation operates on values that become the public ciphertext and is not affected.
Improper neutralization of special elements used in an LDAP query ('LDAP injection') vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (prov modules).
This vulnerability is associated with program files LDAPStoreHelper.
This issue affects BC-JAVA: from 1.74 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.
: Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (core modules).
This vulnerability is associated with program files G3413CTRBlockCipher.
This issue affects BC-JAVA: from 1.59 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.