Bc Lts Java

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.

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.

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.

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.

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.

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.

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.

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.

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.