Electron EUVD-2026-89179

Two concrete prerequisites must both hold: (1) the Electron application must load untrusted content - the advisory explicitly states apps that do not load untrusted content are NOT affected; and (2) the attacker must already control a compromised renderer process (reflected by PR:L and AV:L), meaning renderer-level code execution must be obtained first, e.g. by chaining a separate renderer vulnerability. The specific technical condition is that the sandboxed preload code cache does not verify that a cached entry matches the preload it was served for, allowing the renderer to write a cache entry that is later reused in the preload context. Limiting factors: only Electron versions >=42.3.3,<42.10.0, >=43.0.0-beta.1,<43.5.0, and >=44.0.0-alpha.1,<44.0.0-beta.6 are affected; there are no app-side workarounds (patching is mandatory); and the attack is local/intra-application rather than a standalone remote vector.

This is a genuinely high-impact vulnerability but one gated behind meaningful preconditions, so it warrants prompt patching rather than emergency response. The vendor CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 8.8) correctly models this as a local, low-complexity privilege-escalation requiring an already-compromised renderer (PR:L) that then crosses the sandbox boundary into the privileged preload context (S:C, C:H/I:H/A:H). It is NOT remotely exploitable against a healthy app on its own - AV:L and the description ('a compromised renderer could write attacker-controlled cache data') agree that the attacker must first obtain renderer-level code execution, typically by chaining a separate renderer bug or by the app loading untrusted web content. All exploitation signals point low: EPSS is 0.09% (0th percentile), the vulnerability is NOT in CISA KEV, SSVC records Exploitation=none and Automatable=no, and no public exploit code was identified. These are consistent with each other - there is no conflict between a high CVSS and the low real-world exploitation probability, because the 8.8 reflects the severe technical impact (SSVC Technical Impact=total) while EPSS/SSVC reflect that it is not a standalone, automatable, or currently-exploited bug. The realistic priority is: patch promptly if your Electron app loads untrusted content, de-prioritize if it only ever loads bundled first-party content (the advisory explicitly states such apps are not affected).

An attacker lures a user of an Electron desktop app that loads untrusted web content (or exploits a separate renderer flaw) to gain code execution inside the sandboxed renderer. The compromised renderer writes an attacker-controlled entry into the sandboxed preload code cache, which Electron fails to validate against the preload it was served for; on a subsequent load Electron executes that poisoned cache in the more privileged preload context, escalating out of the renderer sandbox. No public exploit code was identified at time of analysis, and no active exploitation is recorded.