Skip to content

CVE-2026-42770: indicate that 3.1.2 is affected #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
t8m merged 1 commit into from
Jul 20, 2026
Merged

CVE-2026-42770: indicate that 3.1.2 is affected #20

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion secadv/20260609.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -742,7 +742,7 @@ 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
The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 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.
Expand Down
4 changes: 2 additions & 2 deletions secjson/CVE-2026-42770.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,10 +70,10 @@
{
"base64": false,
"type": "text/html",
"value": "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'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'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's<br>own q parameter, not the local key's q. The peer'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'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, and 3.0 are affected by this<br>issue."
"value": "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'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'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's<br>own q parameter, not the local key's q. The peer'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'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."
}
],
"value": "Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)\npeer key, the peer key is not properly checked for the subgroup membership.\n\nImpact summary: A malicious peer which presents an X9.42 key carrying the\nvictim's p and g parameters, a forged q = r (a small prime factor of the\ncofactor (p−1)/q_local), and a public value Y of order r can recover the\nvictim's private key after a small number of key exchange attempts.\n\nWhen EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the\nsubgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's\nown q parameter, not the local key's q. The peer's domain parameters are\nthen matched against the domain parameters of the private key, but the value\nof q is not compared.\n\nA malicious peer who presents an X9.42 key carrying the victim's p, g,\na forged q = r (a small prime factor of the cofactor), and a public\nvalue Y of order r passes all checks. The shared secret then takes only\nr distinct values, leaking priv mod r. Repeating for each small-prime\nfactor of the cofactor and combining via CRT recovers the full private\nkey (Lim–Lee / small-subgroup-confinement attack).\n\nThe realistic attack surface is narrow: principally CMP deployments with\nlong-lived RA/CA DHX keys and bespoke enterprise or government applications\nusing X9.42 DHX static keys with interactive protocols and therefore this\nissue was assigned Low severity.\n\nThe FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are affected by this\nissue."
"value": "Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)\npeer key, the peer key is not properly checked for the subgroup membership.\n\nImpact summary: A malicious peer which presents an X9.42 key carrying the\nvictim's p and g parameters, a forged q = r (a small prime factor of the\ncofactor (p−1)/q_local), and a public value Y of order r can recover the\nvictim's private key after a small number of key exchange attempts.\n\nWhen EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the\nsubgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's\nown q parameter, not the local key's q. The peer's domain parameters are\nthen matched against the domain parameters of the private key, but the value\nof q is not compared.\n\nA malicious peer who presents an X9.42 key carrying the victim's p, g,\na forged q = r (a small prime factor of the cofactor), and a public\nvalue Y of order r passes all checks. The shared secret then takes only\nr distinct values, leaking priv mod r. Repeating for each small-prime\nfactor of the cofactor and combining via CRT recovers the full private\nkey (Lim–Lee / small-subgroup-confinement attack).\n\nThe realistic attack surface is narrow: principally CMP deployments with\nlong-lived RA/CA DHX keys and bespoke enterprise or government applications\nusing X9.42 DHX static keys with interactive protocols and therefore this\nissue was assigned Low severity.\n\nThe FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this\nissue."
}
],
"metrics": [
Expand Down
Loading