CVE-2026-42770

What it actually does

The flaw is an OpenSSL DHX/X9.42 Diffie-Hellman peer-key validation weakness. When applications call EVP_PKEY_derive_set_peer() with a DHX peer key, OpenSSL performs the subgroup membership check using the peer-supplied q value rather than the local private key's q value, and then fails to compare q when matching domain parameters. A malicious peer can supply the victim's p and g parameters, a forged small q value, and a public value Y with small subgroup order. This confines the derived shared secret to a small set of possibilities and leaks information about the victim's private exponent. Repeated exchanges using different small subgroup factors can allow recovery of a long-lived static DHX private key via a Lim-Lee/small-subgroup-confinement attack. The practical impact is confidentiality loss of static DHX private keys in narrow use cases, especially CMP RA/CA deployments or custom protocols using long-lived X9.42 DHX keys.

Why it matters to the business

Organizations using affected OpenSSL FIPS modules in CMP, certificate-management infrastructure, or custom enterprise/government applications with static X9.42 DHX keys could face compromise of long-lived cryptographic private keys. If such keys are recovered, attackers may impersonate trusted parties or decrypt/protect protocol exchanges depending on how the application uses the key material. The overall likelihood is low because exploitation requires a specialized protocol context, repeated interactive key exchanges, and DHX static-key usage; however, the operational consequence can be serious where RA/CA or other high-trust cryptographic services rely on the affected behavior. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no reported public exploit maturity, so remediation should be targeted and risk-based rather than treated as a broad emergency.

How an attack unfolds

An attacker must be able to act as a peer in a protocol that accepts DHX/X9.42 public keys and causes the target application to call OpenSSL EVP_PKEY_derive_set_peer() against a long-lived local DHX private key. The attacker first obtains or infers the target's DHX domain parameters p and g. They then construct a malicious X9.42 peer key that reuses the target's p and g, supplies a forged q equal to a small prime factor of the cofactor, and chooses a public value Y that has that small order. Because OpenSSL validates subgroup membership using the attacker-controlled q and does not compare the peer q to the local q, the malicious peer key can pass validation. The victim derives a shared secret that can take only a small number of values, allowing the attacker to learn the victim private exponent modulo that small factor. By repeating this process across small-prime factors and combining the leaked residues, the attacker can recover the static private key. In realistic deployments this is most relevant to CMP services with long-lived RA/CA DHX keys and bespoke applications using X9.42 DHX static keys in interactive protocols.

How to fix it

Upgrade OpenSSL to a version containing the vendor fix once available for the affected branch, including the affected FIPS modules in the 4.0, 3.6, 3.5, 3.4, and 3.0 lines. Because no exact fixed versions were provided in the input, track the OpenSSL advisory for CVE-2026-42770 and apply the first patched release for the deployed branch, including rebuilding or recertifying dependent FIPS module deployments as required. Prioritize systems that use CMP, RA/CA functions, or custom protocols with X9.42 DHX static keys. Where immediate upgrade is not possible, avoid or disable X9.42 DHX static-key key agreement, rotate away from long-lived DHX keys, prefer ephemeral key agreement with properly validated groups, reject peer-controlled or mismatched domain parameters, and implement an application-level check that the peer q exactly matches the expected local domain q before deriving secrets. Consider rotating exposed long-lived DHX keys after patching if repeated untrusted peer exchanges may have occurred.

How to confirm the fix worked

Confirm the deployed OpenSSL runtime and any linked applications are using a patched OpenSSL build and, where applicable, a patched FIPS provider/module rather than only updated headers or packages. Inventory applications for direct or indirect use of EVP_PKEY_derive_set_peer(), DHX, X9.42 DH, CMP, or static Diffie-Hellman key agreement. Validate that peer DHX parameters are rejected when p and g match expected parameters but q differs from the locally configured q. For high-assurance services, perform a negative test using a deliberately mismatched q value and confirm key derivation fails before shared-secret generation. Review software composition and runtime linkage to ensure statically linked binaries, containers, appliances, and bundled OpenSSL copies have been rebuilt. If long-lived DHX keys were exposed to repeated untrusted peer interactions before remediation, treat key rotation as part of validation closure.

Typical attack path

1. Identify a service or application using OpenSSL DHX/X9.42 key agreement with static, long-lived local private keys.
2. Gain the ability to initiate repeated key-exchange attempts as a protocol peer, such as through CMP or a custom DHX-based protocol.
3. Obtain or infer the target's DHX domain parameters, especially p and g.
4. Generate a malicious X9.42 peer key that reuses p and g but supplies a forged small q value matching a small factor of the cofactor.
5. Choose a public value Y with order equal to the small forged subgroup.
6. Submit the malicious peer key and trigger EVP_PKEY_derive_set_peer() and key derivation on the target.
7. Observe protocol behavior or key-confirmation results to determine which limited shared-secret value was produced, leaking the target private exponent modulo the small subgroup order.
8. Repeat with additional small subgroup factors.
9. Combine recovered residues using the Chinese Remainder Theorem to reconstruct the target's static DHX private key.
10. Use the recovered key to impersonate the affected cryptographic identity or compromise protocol confidentiality, depending on the application design.

How to detect it

There is unlikely to be a universal host or network indicator because exploitation occurs through mathematically valid-looking DHX/X9.42 key exchanges and may not produce crashes or obvious errors. Focus detection on services that use CMP, X9.42 DHX, or custom static Diffie-Hellman protocols. Review application, CMP server, RA/CA, reverse proxy, and network logs for repeated key-agreement attempts from the same source, unusual bursts of enrollment or key-management transactions, authentication or key-confirmation failures surrounding DHX negotiation, and requests carrying varying DHX q parameters while reusing the same p and g. If protocol captures are available, inspect ASN.1/X9.42 DHDomainParameters for peer-supplied q values that differ from the configured local q or are unusually small. On hosts, look for applications or libraries invoking EVP_PKEY_derive_set_peer() with DHX keys and correlate those execution paths with externally initiated sessions. If suspicious activity is found, assume a long-lived DHX private key may have been exposed and rotate it after patching. No named threat actors or active exploitation campaigns were provided for this CVE.

What your security team should do

• First, determine whether OpenSSL is used only for common TLS operations or whether any application uses DHX/X9.42, CMP, or static Diffie-Hellman key agreement; the latter drives real exposure.
• Prioritize certificate-management, RA/CA, government/enterprise bespoke cryptographic services, and systems using OpenSSL FIPS modules in the affected 4.0, 3.6, 3.5, 3.4, or 3.0 lines.
• Apply the vendor-patched OpenSSL release or FIPS module update as soon as it is available for the deployed branch.
• Add compensating controls to reject DHX peer keys where q does not exactly match the expected local q before calling key derivation.
• Reduce exposure by disabling unauthenticated or internet-reachable CMP/DHX endpoints where feasible until patched.
• Rotate long-lived DHX private keys after patching if logs show repeated suspicious key-exchange attempts or if the service accepted untrusted peers.
• Search code repositories and binaries for EVP_PKEY_derive_set_peer, DHX, X9.42, and CMP usage to locate non-obvious affected applications.
• Increase logging around cryptographic negotiation failures, CMP request anomalies, and repeated key-exchange attempts from the same peer identity or network source.
• Do not rely on KEV or EPSS alone for prioritization; although broad exploitation likelihood is low, affected RA/CA-style deployments can have high trust impact.