Published: 2025-10-24
Preface: The Australian government has utilized Bouncy Castle cryptography APIs. Specifically, the Australian Government’s AUSKey project, which was a system for securely accessing government online services, used the Bouncy Castle libraries as its basis for Java cryptography.
Bouncy Castle is a widely-used open-source cryptographic API available for Java and C#, developed and maintained by the Legion of the Bouncy Castle Inc., a registered Australian charitable organization. It is known for its FIPS-certified modules, which meet a recognized government standard for cryptographic modules.
Background: The objective of the Bouncy Castle cryptography project is to provide a comprehensive set of open-source APIs for Java and C# that implement cryptographic algorithms and protocols to build secure applications. It aims to offer a wide range of security features, including those for public key infrastructure, digital signatures, authentication, secure communication, and FIPS-certified cryptographic modules for applications requiring a high level of compliance.
While the javax.crypto.Cipher class and the JCA/JCE frameworks provide the core for cryptographic operations in Java, the Bouncy Castle cryptography library is often needed for below reasons:
Extended Algorithm Support: Bouncy Castle offers a broader range of cryptographic algorithms and modes compared to the default JCE providers, including advanced algorithms like elliptic curve cryptography (ECC) which may not be fully or natively supported by the standard JCE.
Implementation of Emerging Standards: Bouncy Castle frequently incorporates implementations of newer cryptographic standards and protocols before they are fully integrated into the standard JCE, allowing developers to utilize cutting-edge security features.
CVE details: Further issues have shown up in high-core environments with Java 21 and BC-FJA 2.1.1. It appears under very high loads the scheduling of the disposal thread is such that it only gets called rarely, or at least not soon enough. The issue has been fixed by introducing the use of reachability-fencing. This available in Java 9 and later, so Java 8 is still using the disposal daemon as before has been changed to reduce friction (synchronized has been introduced where some friction is still required). A new property has also been added “org.bouncycastle.native.cleanup_priority” which can be set to “min”, “normal”, or “high” (default “min”) in case disposal thread scheduling will be beneficial for Java 8 as well.
Official announcement: Please see the link for details –
https://www.tenable.com/cve/CVE-2025-12194
https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%9012194