CVE-2026-42770

Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)<br /> peer key, the peer key is not properly checked for the subgroup membership.<br /> <br /> Impact summary: A malicious peer which presents an X9.42 key carrying the<br /> victim&amp;#39;s p and g parameters, a forged q = r (a small prime factor of the<br /> cofactor (p−1)/q_local), and a public value Y of order r can recover the<br /> victim&amp;#39;s private key after a small number of key exchange attempts.<br /> <br /> When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the<br /> subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer&amp;#39;s<br /> own q parameter, not the local key&amp;#39;s q. The peer&amp;#39;s domain parameters are<br /> then matched against the domain parameters of the private key, but the value<br /> of q is not compared.<br /> <br /> A malicious peer who presents an X9.42 key carrying the victim&amp;#39;s p, g,<br /> a forged q = r (a small prime factor of the cofactor), and a public<br /> value Y of order r passes all checks. The shared secret then takes only<br /> r distinct values, leaking priv mod r. Repeating for each small-prime<br /> factor of the cofactor and combining via CRT recovers the full private<br /> key (Lim–Lee / small-subgroup-confinement attack).<br /> <br /> The realistic attack surface is narrow: principally CMP deployments with<br /> long-lived RA/CA DHX keys and bespoke enterprise or government applications<br /> using X9.42 DHX static keys with interactive protocols and therefore this<br /> issue was assigned Low severity.<br /> <br /> The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this<br /> issue.