CVE-2026-12185 in BC-JAVA
Summary
by MITRE • 08/03/2026
In Bouncy Castle for Java before 1.85, BKS/UBER keystore allocates from untrusted lengths before integrity check. This issue also affects Bouncy Castle for Java LTS before 2.73.12.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/03/2026
The vulnerability in Bouncy Castle for Java represents a critical memory allocation flaw that occurs during keystore processing operations, specifically affecting the BKS and UBER keystore formats. This issue stems from the library's failure to validate input lengths before allocating memory resources, creating potential vectors for resource exhaustion attacks. The problem manifests when the system processes keystores containing untrusted length parameters, allowing malicious actors to manipulate the allocation process and potentially exhaust available memory resources.
This vulnerability directly relates to CWE-129, which addresses insufficient validation of length values in data structures, and CWE-770, concerning allocation of resources without proper limits. The flaw exists at the core of how Bouncy Castle handles keystore metadata processing, where length fields from external sources are used to determine memory allocation sizes before any integrity checks occur. When processing BKS or UBER formatted keystores, the library accepts potentially malicious length values that can cause excessive memory consumption during allocation phases.
The operational impact of this vulnerability extends across various security-sensitive applications that rely on Bouncy Castle for Java, particularly those handling cryptographic keystores from untrusted sources. Attackers could exploit this weakness by crafting specially malformed keystores that trigger excessive memory allocation, leading to denial of service conditions that disrupt legitimate operations. The vulnerability affects not just standard releases but also the long term support versions, indicating a widespread exposure across different deployment scenarios and maintenance cycles.
The technical exploitation requires an attacker to prepare a malicious keystore file containing oversized or malformed length parameters that will be processed by vulnerable Bouncy Castle implementations. This attack pattern aligns with ATT&CK technique T1499.004, which covers resource exhaustion attacks targeting memory resources through manipulation of allocation parameters. The vulnerability essentially creates a path for attackers to consume excessive system resources without proper validation, potentially leading to application crashes or system instability.
Mitigation strategies include upgrading to Bouncy Castle versions 1.85 and LTS 2.73.12 or later, where the memory allocation process has been modified to validate length parameters before any resource allocation occurs. Organizations should also implement input validation controls at higher layers of their applications to reduce the impact of potentially malicious keystore files. Additional defensive measures include monitoring memory usage patterns in applications using Bouncy Castle and implementing rate limiting for keystore processing operations to prevent exploitation attempts. The fix addresses the core issue by enforcing proper length validation and integrity checking before any memory allocation takes place, ensuring that resource consumption remains within expected bounds regardless of input parameters.