Executive brief
Bouncy Castle for Java is a widely-used cryptographic library that provides SSL/TLS and certificate handling for Java applications. A security misconfiguration causes the library to enable a weaker hostname verification fallback (CN-fallback) by default, even though the documentation states this should be opt-in only. This allows an attacker performing a man-in-the-middle attack to bypass hostname verification and impersonate legitimate servers, potentially compromising encrypted connections and exposing sensitive data.
Technical details
The vulnerability is a configuration/design flaw in Bouncy Castle's JSSE hostname verifier implementation. The CN-fallback mechanism (which falls back to checking the Common Name field in X.509 certificates when Subject Alternative Names are unavailable) is enabled by default despite being documented as an opt-in feature. This affects the JSSE provider in Bouncy Castle for Java, allowing attackers to bypass hostname verification during TLS handshakes when properly exploited in a network-adjacent man-in-the-middle position. The vulnerability requires no authentication or user interaction but does require the attacker to intercept the target connection. Patches are available in Bouncy Castle for Java 1.85+, Java LTS 2.73.12+, and BC-FJA FIPS versions 1.0.24, 2.0.24, and 2.1.24 (respectively for each series).
Affected products
- Bouncy Castle Bouncy Castle for Java before 1.85
- Bouncy Castle Bouncy Castle for Java LTS before 2.73.12
- Bouncy Castle BC-FJA (Bouncy Castle for Java FIPS) before bctls-fips 1.0.24 (1.0.X), 2.0.24 (2.0.X), 2.1.24 (2.1.X)
Timeline
- 2026-08-03: disclosed: Vulnerability published on NVD