CVE‐2026‐59639

Title: CMS verifySignatures returns true for SignedData with zero signers.

Issue affecting: BC before 1.85, BC-LTS before 2.73.12, BC-FJA before bcpkix-fips 1.0.12, 2.0.12 and 2.1.12.

Fixed versions: BC 1.85, BC-LTS 2.73.12, BC-FJA bcpkix-fips 1.0.12, 2.0.12 and 2.1.12.

Platform affected: Java 8 and later.

In Bouncy Castle's CMS implementation, CMSSignedData.verifySignatures(SignerInformationVerifierProvider, boolean) loops over getSignerInfos().getSigners() and returns true after the loop completes. RFC 5652 permits a 'degenerate' SignedData whose signerInfos SET is empty, and neither the ASN.1 layer nor SignerInformationStore rejects an empty collection. An attacker can therefore submit a CMS/PKCS#7 blob with arbitrary eContent and no signers, and verifySignatures() will return true. Applications that treat this return value as proof of authenticity, without separately asserting that an expected signer is present, will accept completely unsigned attacker-controlled content.

The fix was introduced in commit 99ddc6dcc678.