Critical Private Key Recovery in Bouncy Castle for Java (bc-java) - CVE-2026-59650

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.

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.

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.

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.

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.

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.

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.