Bouncy Castle Java EUVD-2026-52023

Exploitation requires the attacker to supply, replace, or tamper with a BKS keystore file that the target application subsequently loads via the default BKS keystore type in an unpatched Bouncy Castle version. The target application must use Bouncy Castle's BKS provider specifically (not SunJKS or PKCS12 formats), and the keystore on disk must be in legacy version 0 or 1 format or the attacker must be able to overwrite the unauthenticated version field to downgrade a version 2 store. Exploitation is further limited to scenarios where the attacker holds write access to the keystore storage path, can intercept keystore retrieval from a network source, or can influence the keystore through supply chain means. Applications that load BKS keystores exclusively from read-only, integrity-protected local storage (e.g., embedded in a signed JAR, protected by OS file ACLs) face substantially reduced practical risk. Authentication requirements are not determinable from CVSS alone, as the PR:N metric reflects that no application-level credentials are needed to supply the file, not that the attacker faces no barriers.

The CVSS 4.0 score of 7.1 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H) reflects a high integrity impact with no confidentiality or availability consequence, and requires passive user interaction - meaning an operator or application must load the crafted keystore. The real-world attack complexity is substantially higher than AC:L implies in isolation: exploitation requires the attacker to first place or tamper with the specific BKS keystore file that the target application loads, which typically demands supply chain access, write access to a deployment environment, or MITM positioning on a network-retrieved keystore. Once file access is achieved, the 16-bit brute-force is trivially fast and forging the MAC is straightforward. No public exploit code and no CISA KEV listing exist at time of analysis, making this a low-urgency but legitimate integrity-bypass risk. Applications loading BKS keystores exclusively from read-only, integrity-protected local storage (e.g., bundled inside a JAR with verified checksums) face substantially lower practical exposure than those loading from network paths or user-influenced locations.

An attacker with write access to a server's BKS keystore file (obtained via misconfigured permissions, supply chain compromise, or interception of a network-fetched keystore) downgrades the version field to v0/1 and brute-forces the 16-bit HMAC key offline in under a second across all 65,536 possible values. The attacker recomputes a valid integrity MAC over a modified keystore containing a rogue trusted certificate authority, causing the target Java application running unpatched Bouncy Castle to silently trust the injected CA and enabling subsequent TLS interception or code-signing bypass. No public proof-of-concept exploit has been identified at time of analysis.