CVE-2026-59638 in Bouncy Castle for Java FIPS
Summary
by MITRE • 08/03/2026
In Bouncy Castle for Java before 1.85, JSSE hostname verifier CN-fallback enabled by default despite documented opt-in. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bctls-fips 1.0.24 (1.0.X series), 2.0.24 (2.0.X series) and 2.1.24 (2.1.X series).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/03/2026
The vulnerability in Bouncy Castle for Java represents a critical security regression where the default configuration enables CN-fallback functionality in the JSSE hostname verifier, despite explicit documentation stating this behavior should be opt-in only. This misconfiguration creates an unintended security risk by automatically falling back to Common Name validation when Subject Alternative Name fields are absent or invalid, effectively bypassing the more secure certificate validation mechanisms that should be enforced by default. The issue affects multiple product lines including standard Bouncy Castle Java releases, Long Term Support versions, and FIPS-compliant variants, indicating a widespread impact across the entire Bouncy Castle ecosystem.
This technical flaw directly relates to CWE-295 which addresses improper certificate validation and can be mapped to ATT&CK technique T1566.001 for credential access through malicious certificates. The CN-fallback mechanism essentially allows attackers to exploit certificate validation weaknesses by presenting certificates with valid Common Names but potentially compromised Subject Alternative Name fields, creating a false sense of security while still enabling man-in-the-middle attacks. The default enablement of this fallback behavior violates the principle of least privilege and secure defaults that should be enforced in cryptographic libraries.
The operational impact of this vulnerability extends beyond simple certificate validation failures to encompass potential credential theft, data interception, and system compromise across any application leveraging Bouncy Castle's SSL/TLS capabilities. Systems using affected versions may unknowingly accept certificates that would normally be rejected, creating attack vectors for various network-based assaults including eavesdropping, session hijacking, and authentication bypasses. The widespread nature of affected product lines means organizations running applications across different Bouncy Castle variants may experience cascading security issues without immediate detection.
Organizations should immediately upgrade to patched versions including Bouncy Castle Java 1.85, LTS 2.73.12, and FIPS variants with appropriate version numbers for each series. The remediation process requires careful attention to ensure that certificate validation policies are explicitly configured according to security requirements rather than relying on potentially insecure defaults. System administrators should conduct comprehensive vulnerability assessments across all applications using Bouncy Castle components and implement monitoring for any unusual certificate validation behavior or potential attacks exploiting the CN-fallback mechanism. Additionally, security teams must review existing certificate management procedures to ensure proper validation policies are enforced and that automated systems do not inadvertently rely on the insecure default configurations.