Electron CVE-2026-115570

Two concrete prerequisites must hold simultaneously: (1) the attacker must possess a TLS certificate issued through one of the specific compromised eMudhra intermediate CAs whose SubjectPublicKeyInfo hashes are added to the blocklist in the fix, and (2) the attacker must occupy an active network-interception (MITM) position on a path the victim Electron app uses for TLS connections via Chromium networking or Node.js tls/https/fetch. The advisory explicitly limits scope: apps are affected only if they make TLS connections over a network an attacker can intercept, and apps that make no network connections are not affected. The flaw is in unpatched default behavior (no non-default setting must be enabled by the victim) because Electron does not consume Chromium's CRLSet and Node.js has no SPKI blocklist. The vendor states there are no app-side workarounds - updating to a patched Electron version is the only remediation.

This is a genuine but conditional man-in-the-middle / server-impersonation flaw (CWE-299, improper certificate revocation handling), not a high-CVSS-but-hollow issue - yet its real-world risk is materially gated by the attack preconditions. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, base 7.4) correctly captures the tension: the vector is network-reachable and needs no privileges or user interaction on the victim app, but AC:H reflects that the attacker must both possess a certificate issued through one of the compromised eMudhra intermediates AND hold a traffic-interception (MITM) position against the target's TLS connections - two non-trivial prerequisites that are not under the attacker's unilateral control. No EPSS score, KEV listing, or SSVC automatable/technical-impact fields were supplied, so those signals cannot be weighed; the only priority signal present is the vuln.today 'this_week' Decision label, consistent with a credential-misissuance class fix rather than an emergency. There is no public exploit - the referenced GitHub PRs and commits are the fixes, not weaponized code. The broader context raises confidence this is real and coordinated: the advisory states the same eMudhra intermediate block shipped in Go (CVE-2026-111943) and Firefox (CVE-2026-113470), indicating an industry-wide trust-revocation event rather than an Electron-specific bug. Net: a defense-in-depth trust-store gap worth patching on a normal urgent cycle, with exploitation realistically limited to adversaries who already control a network path and hold a misissued certificate.

An attacker who controls a certificate issued through one of the compromised eMudhra intermediates positions themselves on the network path (e.g., rogue Wi-Fi, compromised router, or ARP/DNS spoofing) between an Electron app and a server it contacts over TLS. Because an unpatched Electron neither consumes Chromium's CRLSet nor has a Node.js SPKI blocklist, the chain still validates to a trusted root, so the attacker presents the misissued certificate and impersonates the legitimate TLS server, intercepting or altering the app's confidential traffic. No public working exploit was identified at time of analysis; the available references are the vendor advisory and patches.