Fraudulent TLS certificates trusted by Red Hat ca-certificates enable MITM impersonation

The system certificate authority (CA) store in Red Hat products, distributed via ca-certificates RPM packages, included multiple root CA certificates of authorities, which signed intermediate CA certificates with weak private keys issued by the eMudhra certificate authority. A man-in-the-middle attacker could use this flaw to issue certificates for arbitrary host names signed by the weak intermediate CA certificates, which would be considered trusted by a TLS/SSL client using system CA store and cause such clients to connect to malicious sites. Due to inability to only distrust specific intermediate certificates in all clients using the system CA store, root CA certificates of authorities that signed weak intermediate CA certificates are being removed.

Red Hat data identifies the following branches or components as affected:

• Red Hat Enterprise Linux 6, 7, 8, 9, and 10 with ca-certificates; the affected status applies to minor releases unless Red Hat states otherwise.
• Red Hat Hardened Images with ca-certificates and ca-certificates-bundle. The confirmed fix for this image product is 2026.2.92_v9.0.319-1.hum1 in the Hummingbird repositories listed by Red Hat.
• Assisted Installer, cert-manager Operator, Confidential Compute Attestation, Kernel Module Management Operator, Kube Descheduler Operator, Logging Subsystem, Logical Volume Manager Storage, Migration Toolkit for Applications, Migration Toolkit for Containers, Migration Toolkit for Virtualization, Multicluster Engine, Network Observability Operator, OpenShift Serverless, OpenShift Service Mesh 3, Red Hat Advanced Cluster Management 2, Red Hat Advanced Cluster Security 4, and Red Hat Connectivity Link 1.
• Additional products marked affected by Red Hat CSAF include OpenShift Container Platform 4 with RHEL CoreOS 8 and 9, OpenShift Distributed Tracing 3, OpenShift for Windows Containers, OpenShift Virtualization 4 and 5, and Red Hat Quay 3.
• Any Red Hat product supported on RHEL or UBI, including containers and layered products, may be affected if it inherits an unupdated trust store. The normalized record names multiple image and operator packages with rhel8 and rhel9 components.
• Red Hat CSAF currently marks mosquitto.src as part of Red Hat Satellite 6 as not affected. The status of branches or products not listed remains unknown from the available evidence.

Red Hat distributes the system CA store through ca-certificates RPM packages. That trust store contained multiple root CAs that had signed intermediate CAs issued by eMudhra with weak private keys. If an attacker possesses one of the affected private keys and has a man-in-the-middle position to intercept TLS connections, the attacker can issue certificates for arbitrary hostnames that a TLS/SSL client using the system CA store may accept as trusted.

Red Hat is removing related root CAs instead of trying to distrust individual intermediate CAs because not all clients using the system CA store support selective distrust of an intermediate. The specific cryptographic weakness in the private keys and the complete set of affected certificates are not established in the supplied evidence; root names mentioned in mitigation guidance should not be assumed to represent every affected trust store.

The issue is reachable over the network when a client makes a TLS connection and the attacker can occupy a man-in-the-middle position. The attacker does not need an account on the target system, but must possess one or more compromised private keys and must intercept a TLS connection made by a user or application.

Practical attack complexity is high because the attacker needs the appropriate private key, a position to intercept traffic, and a client that still trusts the relevant certificate chain. The supplied evidence does not establish a named public exploit, campaign, or observed exploitation. That absence of evidence does not prove that exploitation has not occurred.

The technical outcome is that a TLS/SSL client may validate a fraudulent certificate for an arbitrary hostname because its chain anchors to a root CA that remains trusted. If the attacker can intercept the connection, transmitted data may be read or modified, and users or applications may be directed to an impersonating service.

The direct effect is on the confidentiality and integrity of TLS connections, not on code execution or operating-system takeover. Scope depends on which clients use the system CA store containing the related trust anchors; applications using a separate trust store or already distrusting those roots may not be affected. The record does not establish that any particular system was compromised.

If a client still trusts an affected certificate chain and the connection is intercepted, an attacker could:

• Impersonate the hostname or website that the client intended to reach.
• Read sensitive data sent over TLS, potentially including credentials, tokens, or application data.
• Modify requests or responses before delivery without triggering the normal certificate validation failure.
• Weaken TLS protection for HTTPS, internal service communication, and other certificate-validated connections.

These are possible technical consequences under the stated attack conditions. The supplied evidence does not confirm a particular data exposure, intrusion, or campaign.

1. Update the system trust store using the Red Hat erratum for the deployed product. For Red Hat Hardened Images, the confirmed fixed packages are ca-certificates-2026.2.92_v9.0.319-1.hum1 and ca-certificates-bundle-2026.2.92_v9.0.319-1.hum1. Do not treat this package version as an open-ended fix statement for other Red Hat branches without a corresponding package or erratum.
2. For affected products without a product-specific fixed package in the Red Hat data reviewed, monitor for and apply the product-specific erratum when released. The current CSAF data records those product groups as affected with no remediation available.
3. Until updates are applied, use the Red Hat blocklist procedure for the related root CAs. The bulletin identifies Comodo AAA Services and emSign ECC Root CA - G3 as related roots to consider. Follow the product-specific Red Hat procedure because removing a root can affect other otherwise valid certificate chains.
4. Update RHEL or UBI base images and rebuild all derived containers. Recheck layered products and OpenShift workloads that consume RHEL packages or images.
5. After updating, verify both the package and the effective trust store no longer trust the affected certificates. Do not treat the absence of a scanner finding as the sole proof of safety when an application uses a separate trust store.

1. Inventory hosts, images, containers, and layered products based on Red Hat Enterprise Linux, RHEL CoreOS, or UBI, especially components that use ca-certificates.
2. On RPM-based systems, check the installed package with the command specified by Red Hat:

rpm -q ca-certificates

1. Determine whether the system trust store still trusts certificates or roots related to eMudhra. Red Hat identifies Comodo AAA Services and emSign ECC Root CA - G3 as roots to consider for blocklisting.
2. Compare installed packages and images with the applicable Red Hat errata. Do not rely only on a scanner that infers status from a package version.
3. For containers, recheck the base image after it is updated and rebuild derived images. TLS logs can be reviewed for unexpected certificate chains or hostname mismatches as a precaution, but this is not a Red Hat-confirmed indicator of compromise. The absence of anomalous logs does not prove that a system is safe.