CVE-2026-59639 in Bouncy Castle for Java
Summary
by MITRE • 08/03/2026
In Bouncy Castle for Java before 1.85, CMS verifySignatures returns true for SignedData with zero signers. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/03/2026
The vulnerability in Bouncy Castle for Java versions prior to 1.85 represents a critical security flaw in the CMS signature verification process that fundamentally undermines the integrity of digital signatures. This issue affects the SignedData structure's ability to properly validate cryptographic signatures when the signer count is zero, creating a scenario where verification operations incorrectly return positive results even when no actual signatures exist within the data structure.
The technical implementation flaw stems from how the verifySignatures method processes CMS (Cryptographic Message Syntax) structures containing zero signers. In legitimate cryptographic operations, SignedData objects should require at least one valid signature to be considered authentic and verified. However, the vulnerable implementations fail to properly validate this fundamental requirement, allowing malformed or incomplete SignedData structures to pass verification when they should fail completely.
This vulnerability directly impacts the security posture of systems relying on Bouncy Castle for Java for cryptographic operations, particularly those implementing digital signature validation for documents, certificates, or secure communications. The flaw creates a potential attack vector where malicious actors could construct SignedData objects with zero signers and have them accepted as valid by systems using affected versions, effectively bypassing the entire signature verification mechanism.
The operational impact extends beyond simple signature validation failures to encompass broader trust model compromises within applications utilizing Bouncy Castle for Java. Systems that depend on proper signature verification for authentication, document integrity, or non-repudiation may be rendered ineffective since they cannot distinguish between properly signed documents and those with zero signers. This weakness particularly affects environments where CMS-based cryptographic operations are critical for security enforcement.
Security standards such as CWE-347 and CWE-327 directly relate to this vulnerability, as it represents a failure in cryptographic validation mechanisms that should enforce proper signature requirements. The issue also aligns with ATT&CK technique T1556.001 concerning credential harvesting through the exploitation of cryptographic weaknesses in software libraries. Organizations using affected versions face significant risks in compliance scenarios where digital signatures must prove authenticity and integrity.
The vulnerability affects multiple Bouncy Castle variants including the standard Java library, Long Term Support releases, and FIPS-compliant implementations across various series, indicating a systemic flaw rather than isolated component failure. This widespread impact requires comprehensive remediation across all affected systems and applications that depend on these cryptographic libraries for security operations. The specific versions mentioned indicate that both current and legacy support branches require immediate attention to prevent exploitation.
Mitigation strategies must include immediate upgrade to Bouncy Castle versions 1.85 or later for standard releases, 2.73.12 or later for LTS versions, and appropriate FIPS versions within their respective series. Organizations should also implement additional validation checks in their applications to explicitly verify the presence of signers before accepting CMS verification results. Runtime monitoring for unexpected zero-signer structures and comprehensive testing of cryptographic operations should be implemented as additional defensive measures against exploitation of this vulnerability.