Five new vulnerabilities in Bouncy Castle Java, the popular cryptography library for Java applications, require immediate dependency checking. Entries CVE-2026-58059 through CVE-2026-58063 affect different functions, from public key verification to certificates and keystores.
The most serious of the five vulnerabilities is CVE-2026-58062, which is rated CRITICAL with CVSS 9.3. According to the CVE Feed, the library could accept a stapled OCSP response without properly associating it with the certificate being checked.
See also: Older Bouncy Castle authentication bypass vulnerability
What does Bouncy Castle Java fix?
The vulnerabilities were published at the same time and cover different points in the same trust chain. This means that an application may not use all of the vulnerable functions, but administrators should not rely on this assumption without checking the code and libraries loaded at startup.
Special consideration is needed for services that act as TLS gateways, issue or verify certificates, and manage key material. In these environments, an OCSP response or keystore file might come from an external system, partner, or automated deployment workflow. Verifying the origin and logging failed checks helps mitigate risk.
CVE -2026-58059 concerns the processing of X.500 distinguished names. A specially crafted name could cause a quadratic increase in character escape time, resulting in significant resource consumption. The CVE Feed rates it HIGH with a CVSS of 8.7 and states that it is potentially exploitable remotely.
CVE -2026-58060 affects HSS public key verification. The unlimited number of levels could lead to a huge memory allocation, while CVE-2026-58061 allowed functions in the CCM family to write the decrypted text to the buffer before the integrity label was checked. Both entries have a HIGH rating and CVSS 8.7.
For applications using HSS or CCM, checks should cover both normal flow and discarded data. Testing should not be limited to successful verifications: it is necessary to confirm that invalid signatures, excessive levels, and failed integrity labels are discarded without uncontrolled memory consumption or exposure of intermediate content.
Finally, CVE-2026-58063 concerns BCFKS keystore loading. An untrusted file could impose an unbounded KDF cost during loading, increasing the risk of resource exhaustion. This vulnerability is rated MEDIUM with CVSS 5.3, but remains significant for services that open keystores from unverified sources.
See also: Post-quantum cryptography and the new security requirements
Which versions should be upgraded?
The five entries affect Bouncy Castle Java prior to version 1.85 and Bouncy Castle LTS prior to 2.73.12. FIPS users should check their branch separately: the fixes are reported in bc-fips versions 1.0.2.7, 2.0.2, and 2.1.3 or later, depending on the order used. Version 1.85 is the base reference for Bouncy Castle Java.
In Maven and Gradle projects, looking for the immediate version is not enough, because different packages may bring older files through indirect dependencies. The development team must examine the dependency tree, remove duplicate versions, and verify that the file ultimately included in the package is the corrected version. The same applies to container images and services that maintain their own JAR directory.
The SecNews technical team recommends documenting all direct and indirect dependencies, checking JAR files loaded into production, and testing the upgrade in a simulation environment. Development teams should also consider whether their applications verify OCSP responses, load BCFKS keystores, or accept cryptographic data from untrusted sources.
Pre-installation checks
Before deployment, developers should back up cryptographic settings, check compatibility with the Java versions being used, and retest TLS, signatures, and keystores. After the upgrade, monitoring for errors and unusual delays can show whether a service is still loading an old library.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
See also: Why modern cryptography needs constant upgrading
The upgrade should be combined with a re-examination of certificate management policies, memory limits, and keystore origins. Organizations that cannot immediately move to the fixed version should temporarily restrict untrusted logins and monitor failed authentications until the updated Bouncy Castle Java is installed.
