Bouncy Castle for Java Cryptographic Vulnerabilities

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.