FFC-DH Peer Validation Uses Attacker-Supplied q
FFC-DH Peer Validation Uses Attacker-Supplied q (CVE-2026-42770) Severity: Low
Issue summary: When EVPPKEYderivesetpeer() is called with a DHX (X9.42) peer key, the peer key is not properly checked for the subgroup membership.
Impact summary: A malicious peer which presents an X9.42 key carrying the victim's p and g parameters, a forged q = r (a small prime factor of the cofactor (p−1)/qlocal), and a public value Y of order r can recover the victim's private key after a small number of key exchange attempts. When EVPPKEYderivesetpeer() is called with a DHX (X9.42) peer key, the subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's own q parameter, not the local key's q. The peer's domain parameters are then matched against the domain parameters of the private key, but the value of q is not compared.
A malicious peer who presents an X9.42 key carrying the victim's p, g, a forged q = r (a small prime factor of the cofactor), and a public value Y of order r passes all checks. The shared secret then takes only r distinct values, leaking priv mod r. Repeating for each small-prime factor of the cofactor and combining via CRT recovers the full private key (Lim–Lee / small-subgroup-confinement attack).
The realistic attack surface is narrow: principally CMP deployments with long-lived RA/CA DHX keys and bespoke enterprise or government applications using X9.42 DHX static keys with interactive protocols and therefore this issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are affected by this issue.
OpenSSL 4.0, 3.6, 3.5, 3.4, and 3.0 are vulnerable to this issue.
OpenSSL 1.0.2 and 1.1.1 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.1. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.3. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.7. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.6. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.21.
This issue was reported on 16th April 2026 by Alex Gaynor (Anthropic). The fix was developed by Alex Gaynor (Anthropic), Viktor Dukhovni and Norbert Pocs.
Issue summary: Applications using AES-CFB128 encryption or decryption on systems with AVX-512 and VAES support can trigger an out-of-bounds read of up to 15 bytes when processing partial cipher blocks.
Impact summary: This out-of-bounds read may trigger a crash which leads to Denial of Service for an application if the input buffer ends at a memory page boundary and the following page is unmapped. There is no information disclosure as the over-read bytes are not written to output.
The vulnerable code path is only reached when processing partial blocks (when a previous call left an incomplete block and the current call provides fewer bytes than needed to complete it). Additionally, the input buffer must be positioned at a page boundary with the following page unmapped. CFB mode is not used in TLS/DTLS protocols, which use CBC, GCM, CCM, or ChaCha20-Poly1305 instead. For these reasons the issue was assessed as Low severity according to our Security Policy.
Only x86-64 systems with AVX-512 and VAES instruction support are affected. Other architectures and systems without VAES support use different code paths that are not affected.
OpenSSL FIPS module in 3.6 version is affected by this issue.