Bouncy Castle CVE-2026-59650

Exploitation requires the target to use Bouncy Castle's MTI/A0 / DHAgreement key agreement with a STATIC or REUSED DH private key - the small-subgroup confinement attack recovers the private exponent only because the same key processes many crafted peer values. The attacker must be a DH protocol peer able to submit chosen public values (the raw 'message' BigInteger and/or a DHPublicKeyParameters whose overridden getY() returns a weak element such as 1, p-1, or p) across repeated exchanges, then perform CRT reconstruction. Limiting factors: deployments using per-session EPHEMERAL DH keys are not practically exploitable (a single-use exponent is not worth recovering); exploitation is not a single request but an iterative oracle attack; and it only applies to callers of the DHAgreement code path, not to unrelated Bouncy Castle crypto. No user interaction or authentication to the DH exchange itself is required.

Signals are mixed and require judgement. The published CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N, score 9.3) rates this critical with no attack complexity or requirements, but that conflicts with the actual mechanics: a small-subgroup confinement / invalid-curve-style attack that recovers a private key requires the local key to be STATIC or REUSED and typically many crafted exchanges plus CRT reconstruction - real prerequisites the base vector's AC:L/AT:N does not reflect. I independently assess higher attack complexity (see assessed vectors). There is no CISA KEV entry and no POC referenced, so this is a serious cryptographic weakness but not evidence of active exploitation. EPSS was not provided in the input, so no exploitation-probability estimate is available. Net: high-priority for any deployment using Bouncy Castle DHAgreement with long-term/static DH keys; lower practical urgency where only ephemeral, per-session DH keys are used, since single-use keys are not meaningfully recoverable.

A server uses Bouncy Castle's DHAgreement with a long-term (static) DH private key. A malicious client repeatedly initiates key agreements sending crafted peer values such as 1, p-1, or p, each leaking the server's private exponent modulo a small factor; the attacker then combines the residues via CRT to reconstruct the full static private key and decrypt or impersonate traffic. No POC is referenced in the available data, and exploitation requires many crafted exchanges rather than a single request.