Bouncy Castle Java CVE-2026-59641

Exploitation requires three concrete conditions: (1) The target application must invoke Bouncy Castle's SignedMailValidator to process S/MIME signed messages - applications that do not use this specific class are unaffected. (2) The caller must NOT have set an explicit date on the PKIXParameters object passed to the validator; if PKIXParameters.setDate() has been called with a trusted instant (e.g., the current system time), the patched and unpatched behavior are identical for that caller. (3) The attacker must possess a private signing key whose corresponding certificate was at some point accepted by the target's PKIX trust store but has since been revoked or has expired. Limiting factors include: the attacker must have previously held a legitimate, trusted signing certificate; the target must be processing externally-sourced S/MIME messages; and revocation checking (CRL/OCSP) must be configured in the PKIXParameters, since if revocation checking is disabled the vulnerability is moot. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) reflects that no privileges on the target system are required, but the signing-certificate prerequisite is a real-world barrier absent from that score.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H) reflects high integrity impact with no special preconditions on the target system, which is accurate for automated mail-processing pipelines that call SignedMailValidator without pinning a trusted date. However, practical exploitation requires the attacker to control a signing certificate that was at some point trusted by the target's PKIX trust store, which is a non-trivial prerequisite not captured by CVSS. EPSS data is not present in the provided intelligence, and neither KEV status nor a standalone POC document has been identified - the only exploit evidence is the regression test added in the patch commit. Real-world priority should be elevated for any deployment processing S/MIME signatures from external parties (email gateways, document signing workflows, secure messaging), particularly where certificate revocation or expiry enforcement is a compliance requirement. For deployments where PKIXParameters.setDate() is already explicitly set by the calling application, the impact is effectively zero, which the patch confirms by making caller-supplied dates take precedence.

An attacker whose signing certificate was revoked or has expired obtains or retains the private key material. They craft an S/MIME signed message embedding a CMS signingTime attribute set to a date within the certificate's original validity window - before revocation or expiry - and send it to a target application (e.g., an enterprise email gateway or document verification service) running an unpatched Bouncy Castle SignedMailValidator without a caller-supplied PKIXParameters date. The validator evaluates the certificate chain as of the attacker-controlled date, finds the certificate valid, and accepts the signature despite the certificate being revoked or expired at the actual current time.