Red Hat ca-certificates EUVD-2026-107565

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.

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.

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).