This is a memory allocation vulnerability in Bouncy Castle's BKS and UBER keystore file parsing. When loading these keystores, the library reads a length field directly from the untrusted file and uses it to allocate a byte buffer before performing any integrity verification. By supplying an artificially large length value, an attacker can force the JVM to attempt allocation of huge buffers — gigabytes or more — causing OutOfMemoryError conditions or heap exhaustion. This is not a cryptanalytic break; it's a classic trust-before-verify failure in the parsing layer.
The affected versions span multiple release branches: 1.71.x through 1.71.3, 1.72.x through 1.72.1, 1.73.x through 1.73.6, and the legacy 2.73.x line before 2.73.12. The fixed release is 2.73.12. If you're using Bouncy Castle in any Java deployment that loads keystores from untrusted sources — configuration files, serialized objects, network-handled keystores — you're exposed.
What makes this noteworthy beyond the CVSS of 7.1 is the blast radius. Bouncy Castle sits at the foundation of Java cryptographic infrastructure: application servers, TLS libraries, enterprise security frameworks, Android's Java crypto stack. The vulnerability isn't isolated to one library — it's a fuse into any system that depends on Bouncy Castle for keystore loading. The parsing code that reads length headers and allocates buffers is shared across all consumers, meaning a single vulnerable codebase propagates exposure across the entire dependency graph.
The EPSS score suggesting low exploitation probability likely reflects reachability challenges rather than intrinsic difficulty. Exploiting this doesn't require code execution — just getting a crafted keystore file loaded by a vulnerable Bouncy Castle instance. Systems that accept keystores from untrusted input (config import, serialized objects, network protocols) are the exposure point. The fact that exploitation produces denial-of-service rather than code execution may explain why it's not a priority target — but heap exhaustion is still a reliable way to take a system down, and many deployments lack sandboxing or memory limits that would contain the damage.
Prioritize upgrading Bouncy Castle to 2.73.12 or later. Audit your systems for code paths that load BKS or UBER keystores from untrusted sources — look for KeyStore.load() calls where the InputStream source is user-controlled, deserialized, or network-derived. If you cannot upgrade immediately, consider adding input size limits or sandboxing around keystore loading code. The underlying format design forces this trust-before-verify pattern, and while a format redesign would be the proper long-term fix, that's a multi-year migration — your immediate exposure is the current version you're running.