CVE-2026-42769
Published: 09 June 2026
Summary
CVE-2026-42769 is a medium-severity Improper Certificate Validation (CWE-295) vulnerability in Openssl Openssl. Its CVSS base score is 5.3 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 17.5th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
Deeper analysis
CVE-2026-42769 is a certificate-validation flaw in OpenSSL's implementation of the Certificate Management Protocol (CMP) root-CA key-update procedure defined in RFC 9810. The affected function, OSSL_CMP_get1_rootCaKeyUpdate, contains a typo in its certificate-chain construction logic that causes the wrong certificate to be added to the chain; as a result, only issuer-name and algorithm-OID checks are performed and the critical signature verification on the newWithOld certificate is bypassed. The vulnerability exists in the non-FIPS portions of OpenSSL that process id-it-rootCaKeyUpdate messages.
An attacker who already possesses valid Registration Authority (RA) credentials satisfying CMP message-protection requirements can craft a malicious key-update response containing a self-signed certificate. Affected CMP clients will accept this certificate as a new trust anchor, allowing the attacker to replace the root-CA certificate and thereby escalate privileges from RA level to full root-CA control. The attack requires network access to a CMP client and valid RA-level authentication, which is why the issue received a CVSS score of 5.3 and Low severity.
Public patches addressing the chain-building error are available in the referenced OpenSSL commits, and the official advisory at openssl-library.org/news/secadv/20260609.txt confirms that FIPS modules are unaffected because the vulnerable code lies outside the module boundary. The current EPSS of 0.0001 shows no material increase since disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-35486
Vulnerability details
Issue Summary: An error in the callback used to verify the certificate provided in a Root CA key update Certificate Management Protocol (CMP) message response rendered the certificate validation ineffectual, which could lead to escalation of credentials from the Registration…
more
Authority (RA) level to the root Certification Authority (root CA) level. Impact Summary: The Registration Autority could replace the root CA certificate for the CMP clients with an arbitrary root CA certificate. One of the parts of the Certificate Management Protocol (CMP), specified in RFC 9810, is Root Certification Authority (root CA) key Rollover, which is sent by the server in a message with type 'id-it-rootCaKeyUpdate'. As part of these messages, 'newWithOld' certificate, the new root CA certificate signed with the old root CA key, is provided, and verifying its signature is crucial for transferring the trust from the old CA key to the new one. The 'id-it-rootCaKeyUpdate' messages are expected to be processed with OSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the 'newWithOld' certificate. A typo in the certificate chain building code led to adding an incorrect certificate ('newWithOld' instead of 'oldRoot') to the certificate chain, rendering the certificate verification process ineffectual (only the issuer name and the algorithm OIDs were verified by other parts of the verification code). An attacker who already has credentials that satisfy the CMP message protection checks can generate a new key pair and use a crafted self-signed certificate in its 'id-it-rootCaKeyUpdate' CMP messages which affected CMP clients would accept as a new trust anchor. Significant preconditions for the attack (having valid RA-level credentials) are the reason the issue was assigned Low severity. The FIPS modules are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
The flaw directly enables an authenticated RA to escalate to root-CA control by forcing acceptance of a malicious trust anchor.
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
When certificates are used to establish component provenance, the control requires correct certificate validation procedures.
Mandates approved trust anchors and issuance policies, directly preventing acceptance of unvalidated or untrusted certificates.
Correct system time is required for proper enforcement of certificate notBefore/notAfter dates and time-based revocation checks.
Hardening callouts derived
Configuration rules from DISA STIG baselines that reduce the attack surface for weaknesses of the type cited by this CVE. Derived transitively via CVE→CWE→STIG over `controls_xwalks` (authoritative rows only).
Oracle Linux 8 (3 rules)
- V-248531 OL 8, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. via CWE-295
- V-248574 YUM must be configured to prevent the installation of patches, service packs, device drivers, or OL 8 system components that have not been digitally signed using a certificate that is recognized and approved by the organization. via CWE-295
- V-248575 OL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-295
RHEL 7 (2 rules)
- V-204447 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-295
- V-204448 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-295
RHEL 8 (2 rules)
- V-230264 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-295
- V-230265 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-295