Bouncy Castle Java CVE-2026-12185

The application must call KeyStore.load() on attacker-controlled data in BKS or UBER format. Exploitation is completely independent of the password supplied to KeyStore.load() because the unbounded allocation occurs in loadStore() before the integrity MAC is verified. No authentication to the Bouncy Castle library itself is required - the constraint is whether the attacker can influence what keystore data the application loads. This limits exploitation to: applications that accept keystore uploads or remote keystore paths, management interfaces that allow keystore configuration, or any pipeline where externally-sourced BKS/UBER files are processed. Applications that load keystores exclusively from static, application-controlled files on disk are not reachable from this attack path. User interaction in the CVSS context (UI:P) reflects that a human or automated process within the target environment must initiate the KeyStore.load() call.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VA:H) correctly captures the core risk profile: network-reachable, low complexity, no privileges required, but dependent on an application or user action that causes KeyStore.load() to be called with attacker-supplied data (UI:P). The availability impact is High - a single crafted file can crash a JVM unconditionally. EPSS data was not provided, so exploitation probability cannot be quantified from that source; however, the combination of a public POC, a trivially small payload, and the pre-MAC bypass makes this mechanically straightforward for any attacker who can influence keystore input. KEV status is not confirmed, so this is not confirmed as actively exploited in production environments. The 'Information Disclosure' tag in the source data appears to be a mislabeling - the actual impact is pure availability (DoS), with no confidentiality or integrity consequences reflected in the CVSS vector. Real-world risk is moderate-to-high for applications that accept or process externally sourced BKS/UBER keystores; negligible where keystores are only loaded from trusted, application-controlled paths.

An attacker who can supply a crafted BKS or UBER keystore file - for example via a file upload endpoint, a configuration interface, or a management API that accepts keystore imports - provides a file of a few dozen bytes with one or more length fields set to Integer.MAX_VALUE. When the target application calls KeyStore.load() on this file, BcKeyStoreSpi immediately attempts to allocate a ~2 GB array before reaching the HMAC check, triggering an OutOfMemoryError that crashes the JVM process or the thread handling the request. A POC was submitted by the researcher alongside the report, confirming this is mechanically trivial.