Bouncy Castle Java EUVD-2026-52035

Exploitation requires: (1) the target application uses Bouncy Castle's CMSSignedData.verifySignatures() as its primary or sole authenticity check for received CMS/PKCS#7 SignedData - applications using lower-level SignerInformation APIs directly or other libraries are not affected; (2) the attacker can supply a crafted CMS envelope to that code path, e.g., via file upload, API call, or network protocol message carrying signed content. Per the CVSS PR:N rating, no authentication is required on the attacker's side. Exploitation is limited to affected versions of bc-java (before 1.85), bc-lts-java (before 2.73.12), and bc-fja (before the per-series patch versions); counter-signature verification is explicitly unaffected per the vendor commit notes. Applications that independently validate signer count before calling verifySignatures(), or that use getCertificates() for degenerate structures, are not exploitable.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VI:H) correctly captures the ceiling risk: zero privileges, zero complexity, network-reachable, and high integrity impact for any affected application using verifySignatures() as a trust boundary. However, actual exploitability is gated on application-level context - specifically whether the target application uses this API as its primary authenticity check and whether an attacker can reach that code path with a crafted CMS envelope. The vulnerability is not listed in CISA KEV and no public exploit code has been identified at time of analysis; EPSS data was not provided in the available intelligence. The urgency rating of Amber (CVSS 4.0 supplemental) indicates elevated but not immediate priority. The tags 'JWT Attack' and 'Information Disclosure' suggest downstream exploitation patterns in applications using CMS for token or credential signing, but these impacts are inferred from context rather than confirmed by the advisory. The integrity-only impact profile (VI:H, VC:N, VA:N) is consistent with a pure signature bypass - no direct data exfiltration or service disruption is implied.

An attacker targeting a firmware update service, document signing platform, or credential validation endpoint that uses CMSSignedData.verifySignatures() constructs a CMS SignedData envelope with an empty signerInfos SET wrapping arbitrary malicious payload. The envelope is submitted to the application's verification endpoint; verifySignatures() iterates zero signers and returns true, causing the application to accept and process the unsigned payload as fully authenticated. No public exploit code has been identified at time of analysis, but the construction is trivial using any standard ASN.1 or CMS library.