Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain man-in-the-middle network position
-
DeliveryForge certificate using weak eMudhra intermediate
-
ExploitVictim TLS client initiates connection
-
ExecutionSystem CA store trusts forged cert
-
ImpactIntercept or redirect to malicious site
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Exploitation requires three concrete conditions: (1) the attacker must hold a man-in-the-middle position on the victim's network path (AC:H), (2) the victim must use a Red Hat system whose ca-certificates-provided system CA store still trusts the eMudhra root CAs that signed the weak intermediate certificates, and (3) a client must actively initiate a TLS/SSL connection that validates against the system CA store (UI:R). The core enabling condition is the presence of weak-private-key intermediate CA certificates chaining to trusted roots, which lets the attacker mint certificates for arbitrary hostnames. Limiting factors: no code execution results (impact is traffic interception/impersonation), the attacker needs an existing interception capability, applications that pin certificates or use a custom/non-system trust store are not affected, and A:N means no availability impact. |
| Impact | This is a moderate-risk cryptographic trust flaw (CWE-295) rather than a remotely-weaponizable code-execution bug, and the signals are internally consistent on that point. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N, base 6.8) tells a coherent story: no authentication is required (PR:N), but exploitation is gated by high attack complexity (AC:H) because the attacker must already hold a man-in-the-middle position AND abuse a weak eMudhra-issued intermediate key, plus user interaction (UI:R) because a victim client must actually initiate a TLS connection the attacker can intercept. No EPSS score was supplied, so exploitation probability cannot be quantified from the input. The CVE is NOT in CISA KEV and no public exploit code is referenced, so there is no evidence of active exploitation - the fix is a defensive trust-store cleanup (removing the offending root CAs) rather than a response to in-the-wild abuse. Net: this is a worth-patching supply-of-trust hygiene issue, not an emergency. The practical blocker is that AC:H/UI:R exploitation requires a pre-existing network interception capability, which bounds real-world risk well below what the C:H/I:H impact metrics alone might suggest. No conflicting signals were observed; the main gap is the absence of EPSS/KEV/POC data to confirm or rule out opportunistic exploitation. |
| Exploit ScenarioDerived | An attacker positioned on the network path (e.g., rogue Wi-Fi, compromised router, or ISP-level interception) uses a weak eMudhra-signed intermediate CA to forge a TLS certificate for a legitimate hostname. When a victim on a Red Hat system that trusts the system CA store connects to that host, the forged certificate validates successfully and the client is silently redirected to or intercepted by an attacker-controlled site. No public exploit code is identified at time of analysis, and the attack requires both a man-in-the-middle position (AC:H) and a user-initiated connection (UI:R). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
The system CA trust store shipped in Red Hat's ca-certificates RPM packages includes eMudhra root authorities that signed intermediate CA certificates protected by weak private keys, so a man-in-the-middle attacker who can intercept traffic and who can factor or guess those keys could mint certificates for arbitrary hostnames that TLS clients using the system trust store would accept (CVSS 6.8, CWE-295). Affected platforms span Red Hat Enterprise Linux 6 through 10 plus a long list of layered products such as OpenShift Container Platform 4, Satellite 6, Quay 3, Advanced Cluster Management, and the cert-manager and logging operators. Attackers need a privileged network position and a victim client that actually initiates a TLS connection validated against the system store, so this is a trust-anchoring and impersonation problem rather than a remotely reachable code-execution flaw; there is no availability impact and no public exploit code identified at time of analysis. Because individual intermediate certificates cannot be selectively distrusted across every consumer of the system store, Red Hat is removing the parent root CAs outright, which is the crux of the remediation.
RemediationAI
The fix is to install the updated ca-certificates package from Red Hat for every affected product line, which deletes the eMudhra root CAs implicated in signing weak intermediate certificates; track availability through the Red Hat vulnerability page at https://access.redhat.com/security/cve/CVE-2026-114406 and the remediation article at https://access.redhat.com/security/vulnerabilities/RHSB-2026-012, and see https://bugzilla.redhat.com/show_bug.cgi?id=2556046 for engineering detail. Because the vendor's approach is root removal rather than intermediate-level distrust, expect collateral breakage for any internal or third-party service whose certificate chain terminates at a removed root, so inventory those dependencies before rollout. Where patching must be staged, the pragmatic compensating controls are to pre-emptively delete the specific eMudhra roots from the trust bundle via the update-ca-trust framework or your image build (trade-off: it breaks any legitimate chain anchored to those roots, which is the same side effect as the official fix, so test against an intercepting proxy or staged client set first), to enable certificate pinning or a curated private trust store in high-value clients such as internal service mesh and API gateways (trade-off: pinning adds rotation overhead and can itself cause outages on legitimate certificate renewal), and to enforce network-path protections so a man-in-the-middle position is harder to obtain, for example mutual TLS on internal links and strict egress control (trade-off: operational complexity and additional certificate lifecycle management). Note that host-level workarounds do not cover containers or appliances with their own baked-in bundles, so rebuild those images from patched base layers as well. No vendor-released patch version numbers were available at time of analysis, so verify the exact fixed package release in the Red Hat advisory before closing out.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is a public-key-infrastructure trust-anchor problem in the CWE-295 (Improper Certificate Validation) class. TLS clients that rely on the operating system bundle - /etc/pki/tls/certs/ca-bundle.crt on Red Hat systems, generated by the update-ca-trust framework from the ca-certificates RPM - treat every self-signed root in that bundle as unconditionally trusted. Classic PKI validation permits any root to issue intermediates, and any such intermediate to issue leaf certificates for arbitrary names, so a root that has vouched for an intermediate with a weak private key transitively extends trust to anyone who can recover or brute-force that intermediate key. The eMudhra-issued intermediates fall into that category, and because most TLS stacks (OpenSSL, GnuTLS, NSS, Go, Java's system-backed trust manager) offer no standard, portable mechanism for distrusting a specific intermediate while retaining its parent root, the vendor's only universal remedy is to delete the affected roots from the bundle altogether. The practical consequence is that the flaw is exploitable only by an adversary already positioned on the network path and only against clients whose trust decisions flow through the system store; applications that pin certificates, ship their own CA bundle, or use a private trust store are insulated, and the CVSS vector's A:N reflects that interception does not degrade availability.
Know when Red Hat Enterprise Linux 10 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
MITM position and weak-key abuse justify AC:H; no auth needed so PR:N; a victim must initiate the connection so UI:R; interception yields C:H/I:H but no A impact.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)CVE.org
More in Red Hat Enterprise Linux 10
View allHeap corruption via double-free in 389-ds-base's LDAP control parsing allows an unauthenticated remote attacker to crash
Remote code execution in Cockpit's web interface allows unauthenticated attackers to execute arbitrary commands on the h
Remote code execution in Samba's printing subsystem allows remote attackers to inject arbitrary shell commands via craft
Ghostscript can execute arbitrary shell commands with the privileges of its process when it renders a crafted PostScript
Use-after-free in librsvg during rendering of crafted SVG documents with nested XInclude directives and duplicate entity
Authentication bypass in 389 Directory Server (shipped as Red Hat Directory Server 11-13 and within RHEL 6-10) lets remo
Remote code execution and privilege escalation in HPLIP (HP Linux Imaging and Printing) affects the hpcups print filter
Unauthenticated privilege escalation in FreeIPA (Red Hat Identity Management) allows a remote attacker to gain genuine a
A heap buffer overflow exists in libsoup's WebSocket permessage-deflate compression path: when a very large outbound mes
Remote code execution in libarchive on 32-bit systems allows unauthenticated attackers to execute arbitrary code via spe
Unauthenticated path traversal in gvproxy, the network forwarder shipped in the gvisor-tap-vsock package (used by Podman
HTTP request smuggling in Undertow (the embedded web server underpinning JBoss EAP, Red Hat Data Grid, and Apache Camel
EUVD-2026-107565
GHSA-jrx5-4fv3-4mcq
NVD
CVE.org
EPSS
Exploit-DB