Bouncy Castle Java EUVD-2026-52088

Exploitation requires that the target application loads a BCFKS-format keystore file whose KDF parameters are attacker-controlled - either because the attacker can write or substitute the keystore file on disk, intercept and replace it during network retrieval, or inject it through any other path by which the application accepts a keystore from an external or untrusted source. The vulnerability fires inside KeyStore.load() before the integrity MAC is verified, so no keystore password is needed to trigger resource exhaustion. Limiting factors: (1) the application must use the BCFKS keystore format specifically (not JKS, PKCS12, or other formats); (2) the application must process a keystore file originating from an untrusted or attacker-reachable source - applications loading keystores exclusively from local, operator-controlled paths are not exposed via remote attack; (3) the CVSS 4.0 vector includes UI:P, indicating the application (or an operator action) must perform the load, which does not occur in all deployment configurations automatically.

The provided CVSS 4.0 score of 5.3 (Medium) reflects a network-reachable, low-complexity, unauthenticated vector that requires only passive user interaction (application loading the keystore) but limits measured impact to low availability in the vulnerable system with no confidentiality or integrity consequence. The upstream reporter assigned Urgency: Amber, indicating elevated but not critical concern. No EPSS score was provided in the intelligence data; no KEV listing and no public exploit code were identified, suggesting exploitation has not been observed at scale. Real-world risk is gated by a non-trivial pre-condition: the target application must be made to load a BCFKS keystore file whose content is attacker-influenced - a condition that is realistic in scenarios involving external keystore provisioning, automated certificate management pipelines, or where an attacker has achieved MitM or supply-chain position. Applications that load keystores exclusively from local, trusted paths face substantially lower exposure. The CVSS impact of VA:L in the provided vector may understate the potential severity: unbounded scrypt parameters could in principle exhaust the full JVM heap, warranting consideration of a higher availability rating.

An attacker who can supply or substitute a BCFKS keystore file - for example by poisoning a network-accessible keystore endpoint, manipulating a certificate automation pipeline, or delivering a malicious file via a phishing vector targeting an operator - crafts the file with a PBKDF2 iteration count near Integer.MAX_VALUE or scrypt parameters sized to fill available RAM. When the target Java application calls KeyStore.load() with the malicious file, the library begins computing the integrity-MAC key using the untrusted KDF parameters before any authenticity check runs, exhausting CPU or memory and rendering the application or service unresponsive. No public exploit code has been identified at time of analysis.