The CVSS score of 8.7 for CVE-2026-59641 is misleading in a way that should change your prioritization. This is not a typical authentication bypass — it is a non-repudiation failure that only works retroactively, against signatures created when the attacker's certificate was still valid. The vulnerability allowed Bouncy Castle's S/MIME handler to use the signer-provided signingTime attribute as the authoritative reference for certificate path validation. This creates a logical circle: the code used a value inside the signed content (and controlled by the signer) to verify whether that signer's own certificate was valid at the time they claim to have signed.
The practical impact is narrower than the CVSS suggests. You cannot exploit this to impersonate a currently-valid identity. You can only retroactively invalidate or cast doubt on signatures made by someone whose certificate has since expired or been revoked — but who legitimately controlled the private key when the signature was created. This makes the vulnerability primarily relevant to archival verification, legal document chains, and contractual integrity, not active session security. The EPSS score of 0.00174 correctly reflects that threat intelligence sees no active exploitation, and the reason is structural: the attack requires the attacker to have been a legitimate signer before their cert's status changed.
The more urgent concern is what the fix uses instead of signingTime for authoritative time. If it substitutes wall-clock time or validation-time as the reference, you now have a different problem: signatures made during a certificate's valid window would retroactively become invalid if validated after expiration. For any system that verifies long-term archives, legal records, or regulatory submissions, this breaks the fundamental guarantee those systems depend on. Demand from your Bouncy Castle update whether the fix implements a time-anchored validation mode — one that remembers the signing context — or whether it simply removes the problematic behavior and leaves you to provide the correct validation time yourself.
Deployments most at risk are those in regulated environments running older Bouncy Castle tracks (LTS, BC-FJA) where update cycles are measured in years, not weeks. These are exactly the contexts where non-repudiation matters most — contractual signing, compliance documentation, architectural approvals. The vulnerability will persist in forgotten deployments long after the patch is available, and the fix itself may introduce silent validation failures that pressure teams to weaken verification rather than handle the temporal semantics correctly.