Bc 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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

Bouncy Castle For Java before 1.74 is affected by an LDAP injection vulnerability. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.

An issue was discovered in Legion of the Bouncy Castle BC Java 1.65 and 1.66. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.

The ASN.1 parser in Bouncy Castle Crypto (aka BC Java) 1.63 can trigger a large attempted memory allocation, and resultant OutOfMemoryError error, via crafted ASN.1 data. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.

Legion of the Bouncy Castle Legion of the Bouncy Castle Java Cryptography APIs 1.58 up to but not including 1.60 contains a CWE-470: Use of Externally-Controlled Input to Select Classes or Code. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.

Bouncy Castle BC 1.54 - 1.59, BC-FJA 1.0.0, BC-FJA 1.0.1 and earlier have a flaw in the Low-level interface to RSA key pair generator, specifically RSA Key Pairs generated in low-level API with added. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.

The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Rated medium severity (CVSS 4.4), this vulnerability is low attack complexity. No vendor patch available.

BouncyCastle TLS prior to version 1.0.3, when configured to use the JCE (Java Cryptography Extension) for cryptographic functions, provides a weak Bleichenbacher oracle when any TLS cipher suite. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and EPSS exploitation probability 66.2%.

The AES-GCM specification in RFC 5084, as used in Android 5.x and 6.x, recommends 12 octets for the aes-ICVlen parameter field, which might make it easier for attackers to defeat a cryptographic. Rated medium severity (CVSS 5.5), this vulnerability is no authentication required, low attack complexity. No vendor patch available.

The TLS implementation in the Bouncy Castle Java library before 1.48 and C# library before 1.8 does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the. Rated medium severity (CVSS 4.0), this vulnerability is remotely exploitable.