CVE-2026-42769

What it actually does

This flaw affects OpenSSL CMP client handling of root CA key rollover messages, specifically id-it-rootCaKeyUpdate responses processed through OSSL_CMP_get1_rootCaKeyUpdate(). During validation of the new root CA certificate, the certificate chain construction used the wrong certificate, making the intended signature verification ineffective. As a result, a party that already has valid CMP message-protection credentials, such as Registration Authority-level credentials, can send a crafted root CA key update that causes vulnerable CMP clients to accept an attacker-controlled root CA certificate as a new trust anchor. The OpenSSL FIPS modules are not affected because the vulnerable CMP code is outside the FIPS module boundary.

Why it matters to the business

Organizations that rely on OpenSSL CMP clients for certificate enrollment or CA rollover could have their trust chain silently redirected by a compromised or malicious Registration Authority. This may allow an attacker to issue certificates trusted by affected clients, undermining mutual TLS, device identity, service authentication, and certificate-based access controls. The likelihood is constrained because the attacker needs valid RA-level CMP credentials and exploitation is not known to be active; EPSS is low and stable, the issue is not in CISA KEV, and no public exploit maturity is reported. However, the impact can be high in environments where CMP is used to manage trust anchors for critical infrastructure, private PKI, IoT fleets, or service identity.

How an attack unfolds

An attacker first obtains credentials that pass CMP message-protection checks, typically by compromising or abusing an account, key, or certificate with Registration Authority-level privileges. The attacker then generates their own CA key pair and creates a crafted root CA key update response containing an attacker-controlled certificate in the newWithOld field. Because vulnerable OpenSSL CMP client code builds the verification chain incorrectly, it fails to properly verify that the new root CA certificate was signed by the existing trusted root CA. The client may therefore accept the attacker-controlled certificate as the replacement root trust anchor. After trust is redirected, the attacker can issue certificates chaining to their own root CA and use them wherever those affected CMP clients rely on the updated trust anchor, enabling impersonation or unauthorized certificate-based access.

How to fix it

Upgrade OpenSSL to a vendor-fixed release as soon as fixed versions are available from the operating system, appliance, container base image, or software vendor. Because no exact fixed versions were provided in the input, track the OpenSSL advisory and downstream package advisories for the corrected builds. Prioritize systems that actively use CMP client functionality, especially OSSL_CMP_get1_rootCaKeyUpdate(), automated certificate enrollment, RA-based issuance workflows, or root CA rollover. If immediate patching is not possible, mitigate by disabling CMP root CA key update processing, disabling automated root trust anchor rollover, requiring out-of-band approval for root CA changes, pinning the expected root CA certificate or fingerprint, restricting which RA credentials can send CMP responses, rotating exposed RA credentials, and limiting network access to CMP services. OpenSSL FIPS module-only usage is not affected, but applications using non-FIPS CMP code paths still require review.

How to confirm the fix worked

Confirm whether any deployed software uses OpenSSL CMP client functionality, not merely whether OpenSSL is installed. Inventory applications, appliances, SDKs, containers, and embedded systems that call CMP APIs or perform automated CA enrollment/rollover. Verify the OpenSSL package or embedded library version against the relevant vendor advisory once fixed versions are published. Review CMP client configuration to determine whether root CA key updates are accepted automatically. In a controlled test environment, validate that a rootCaKeyUpdate message containing a certificate not signed by the existing trusted root is rejected. Confirm that trust stores, pinned CA fingerprints, or CMP client state have not been changed unexpectedly. For production validation, compare current trusted root CA certificates and fingerprints against approved PKI records.

Typical attack path

1. Identify systems or products using OpenSSL CMP client functionality for certificate enrollment or root CA rollover.
2. Obtain valid CMP message-protection credentials with Registration Authority-level privileges or equivalent authorization.
3. Generate an attacker-controlled CA key pair and certificate intended to become the new root trust anchor.
4. Craft a CMP id-it-rootCaKeyUpdate response containing the malicious certificate in the root CA rollover structure.
5. Deliver the crafted CMP response to vulnerable CMP clients during enrollment, update, or rollover processing.
6. Cause the vulnerable client to accept the attacker-controlled root CA certificate as the updated trust anchor.
7. Issue certificates from the attacker-controlled CA and use them to impersonate services, devices, users, or infrastructure trusted by the affected clients.

How to detect it

Look for evidence of unauthorized CMP root CA rollover and unexpected trust-anchor changes. Relevant sources include CMP server and client logs, PKI/RA audit logs, certificate enrollment logs, application logs from CMP-enabled products, endpoint file integrity monitoring for trust stores, configuration management records, and network captures from CMP traffic. Focus on id-it-rootCaKeyUpdate messages, especially those initiated by unusual RA identities, sent outside planned rollover windows, or resulting in a new root CA certificate whose fingerprint does not match approved PKI records. Review certificate stores and CMP client state for newly added or replaced root CA certificates. Hunt for certificates issued after the suspected event that chain to an unapproved root CA. Because exploitation requires valid CMP message-protection credentials, also review authentication logs for RA accounts, key usage anomalies, unusual source IPs, and unexpected certificate-signing or certificate-management activity. There are no known public exploitation campaigns or KEV-driven indicators from the provided data, so detection should be behavior- and artifact-based rather than signature-only.

• id-it-rootCaKeyUpdate
• 1.3.6.1.5.5.7.4.17
• OSSL_CMP_get1_rootCaKeyUpdate
• newWithOld
• rootCaKeyUpdate
• unexpected root CA rollover
• unapproved root CA certificate
• self-signed root CA certificate accepted
• CMP root CA key update
• Registration Authority credential used for root CA update

What your security team should do

• Prioritize inventory of systems that use OpenSSL CMP client functionality; ordinary TLS use of OpenSSL without CMP root CA rollover is not the primary exposure.
• Monitor OpenSSL and downstream vendor advisories for fixed versions and patch CMP-enabled systems promptly when updates are available.
• Temporarily disable automatic CMP root CA key update processing where operationally feasible.
• Require manual, out-of-band validation for any root CA rollover event until patched.
• Restrict CMP endpoints and RA-authorized credentials to the smallest necessary set of systems and identities.
• Review and rotate RA-level CMP credentials if compromise, misuse, or unexpected CMP activity is suspected.
• Add monitoring for id-it-rootCaKeyUpdate CMP messages and unexpected trust-anchor changes on CMP clients.
• Compare deployed root CA certificate fingerprints against approved PKI baselines to identify unauthorized rollover.
• Investigate any new certificates chaining to unapproved or recently introduced internal root CAs.
• Document whether products using OpenSSL FIPS modules also invoke non-FIPS CMP code paths, because the vulnerable code is outside the FIPS boundary.