A flaw in Bouncy Castle for Java caused the hostname verifier to enable CN‑fallback by default, even though the library’s documentation states that this feature requires explicit opt‑in. This weakness means that a client library could accept a certificate whose Common Name does not match the hostname it is connecting to, potentially allowing a malicious server to impersonate another site. The result is a classic man‑in‑the‑middle scenario where sensitive data can be intercepted, altered, or logged by an attacker, compromising confidentiality and integrity.

The vulnerability affects Legion of the Bouncy Castle Inc. products: Bouncy Castle for Java before version 1.85, Bouncy Castle for Java LTS before version 2.73.12, and Bouncy Castle for Java FIPS before bctls‑fips 1.0.24 (1.0.X series), 2.0.24 (2.0.X series) or 2.1.24 (2.1.X series).

The CVSS score of 9.3 indicates a high‑severity vulnerability with full remote impact. EPSS data is unavailable, so the exploitation probability is not quantified, but the lack of a KEV listing does not diminish the risk to environments that rely on the affected Bouncy Castle libraries. Attackers would need to position themselves between the client and the intended server, presenting a forged certificate that would pass validation, a scenario that is both realistic and potentially catastrophic in high‑trust deployments.