CVE-2026-34780: Electron: Context Isolation bypass via contextBridge VideoFrame transfer
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 39.0.0-alpha.1 to before 39.8.0, 40.0.0-alpha.1 to before 40.7.0, and 41.0.0-alpha.1 to before 41.0.0-beta.8, apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script. Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected. This issue has been patched in versions 39.8.0, 40.7.0, and 41.0.0-beta.8.
Security readout for executives and security teams
Plain-English summary
This affects Electron desktop apps only in a narrow pattern: the app must expose WebCodecs VideoFrame objects from a preload script through contextBridge. If an attacker can run JavaScript in the page, such as through XSS, they may cross Electron’s context isolation boundary and reach APIs intended to stay isolated.
Executive priority
Prioritize patching affected Electron apps that display untrusted content or expose powerful preload APIs. The issue is high severity but conditional, so triage depends on whether the application bridges VideoFrame objects and whether attackers can reach renderer JavaScript execution.
Technical view
Electron 39, 40, and 41 prerelease ranges before the named patched releases allow a context isolation bypass when VideoFrame objects are transferred through contextBridge.exposeInMainWorld(). Impact can include access to isolated-world capabilities, including Node.js APIs exposed to preload code.
Likely exposure
Exposure is likely limited to Electron applications using affected versions and explicitly bridging VideoFrame objects to the main world. Apps that do not pass, return, or resolve VideoFrame objects through contextBridge are stated as not affected.
Exploitation context
The sources describe exploitation as requiring attacker-controlled JavaScript in the main world, such as XSS, and user interaction per CVSS. The bundle does not report active exploitation, and KEV is false.
Researcher notes
The key research question is whether a target preload boundary exposes VideoFrame through contextBridge. Avoid broad assumptions: Electron apps without this bridge pattern are not affected according to the advisory. No exploit-in-the-wild evidence is present in the supplied sources.
Mitigation direction
Upgrade Electron to 39.8.0, 40.7.0, 41.0.0-beta.8, or later applicable releases.
Stop passing VideoFrame objects through contextBridge until the application is patched.
Audit preload APIs exposed with contextBridge.exposeInMainWorld().
Reduce renderer XSS exposure, especially where untrusted content is displayed.
Check Electron and downstream vendor guidance for product-specific updates.
Validation and detection
Inventory Electron versions across desktop applications and packaged builds.
Search preload code for contextBridge.exposeInMainWorld() usage.
Confirm no preload API passes, returns, or resolves VideoFrame objects.
Verify patched Electron versions are present in shipped artifacts.
Review renderer inputs and routes that could allow JavaScript execution.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-1188: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-1188 · source CWE mapping
Initialization of a Resource with an Insecure Default
Initialization of a Resource with an Insecure Default represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Trust Boundary Violation represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Exposure of Resource to Wrong Sphere represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.