EUVD-2026-107362
GHSA-3qxv-5xgr-q7w9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain code execution in GPU process (prerequisite)
-
DeliverySend frame with inconsistent geometry over Mojo
-
ExploitMain process wraps undersized mapping as bitmap
-
ExecutionOut-of-bounds read during frame capture
-
ImpactDisclose main-process memory or crash app
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires two concrete preconditions. First, the Electron application must actually use webContents.beginFrameSubscription (i.e., frame/offscreen capture is enabled) - apps not using this API are not exposed. Second, the attacker must have ALREADY achieved arbitrary code execution inside the GPU process via a separate, unrelated vulnerability; this bug is only reachable from a compromised GPU process supplying malicious frame metadata (content_rect, coded_size, pixel_size, pixel_format) that the pre-patch main process trusted without bounds-checking against the actual shared-memory/IOSurface mapping. Affected versions are those prior to 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9. The high-complexity, high-privilege prerequisite (GPU-process code execution) is the dominant limiting factor and is why real-world risk is far lower than the technique tags suggest. |
| Impact | This is a genuinely low-priority issue despite the alarming 'RCE'/'Buffer Overflow' tags, and the signals are internally consistent on that point. The CVSS 3.1 vector (AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L, 3.9 LOW) encodes a steep precondition: the attacker must ALREADY possess code execution inside the sandboxed GPU process (PR:H), and the attack path is high-complexity (AC:H) and local (AV:L) rather than network-reachable. The scope change (S:C) is the only noteworthy element - it reflects a compromised GPU process corrupting the more-privileged main (browser) process. Impact is limited to C:L (partial memory disclosure) and A:L (crash), with I:N (no integrity/code-execution gain), which directly contradicts the 'RCE' tag - there is no arbitrary code execution outcome described. No EPSS score, no CISA KEV listing, and no public exploit were provided; absence of these is expected for a defense-in-depth sandbox-escape-adjacent bug and should not be read as suppressed risk. In short: this is a hardening fix for an out-of-bounds read reachable only after a prior GPU-process compromise, not a high-real-risk flaw. The main caveat is that it becomes meaningful only as the second stage of an exploit chain where a GPU-process RCE already exists. |
| Exploit ScenarioDerived | An attacker first chains a separate vulnerability (e.g., a GPU-process memory-corruption bug) to run code inside Electron's GPU process. From there, when the application uses webContents.beginFrameSubscription, the attacker sends frames whose declared geometry (content_rect / coded_size / pixel_size) is inconsistent with the actual shared-memory or IOSurface mapping, causing the trusted main process to read beyond the buffer while building the captured bitmap, leaking main-process memory or crashing the app. No public exploit identified at time of analysis; exploitation requires high complexity and pre-existing GPU-process code execution. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Out-of-bounds memory read in Electron's frame-capture path (webContents.beginFrameSubscription) affects all versions prior to 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9. The main process trusted frame geometry and pixel-format metadata relayed from the GPU process - content_rect, coded_size, pixel_size, and pixel_format - without validating it against the actual shared-memory or IOSurface mapping, so a malicious set of values causes the browser to read past the end of the buffer while assembling captured frames, leaking process memory or crashing the app. Exploitation requires that the target application actually use the frame-subscription API and that the attacker already hold code execution inside the GPU process through some other bug; no public exploit code and no active exploitation were identified at time of analysis, and the CVSS 3.9 score reflects that steep prerequisite rather than the severity of the memory-safety class.
RemediationAI
Vendor-released patch: upgrade to Electron 42.11.6, 43.7.3, 44.4.3, or 45.0.0-alpha.9 (release notes at https://github.com/electron/electron/releases/tag/v42.11.6, /v43.7.3, /v44.4.3, /v45.0.0-alpha.9; advisory GHSA-3qxv-5xgr-q7w9). Applications that embed Electron must rebuild and reship their bundled runtime - updating a package.json dependency without producing a new distributable leaves end users on the vulnerable binary. Where upgrading immediately is not possible, the most effective compensating control is to eliminate the attack surface: audit the codebase for webContents.beginFrameSubscription and disable frame-capture or offscreen-rendering features that depend on it, accepting the loss of that functionality (screen sharing, preview thumbnails, headless capture) as the trade-off. Because the flaw is only reachable from an already-compromised GPU process, hardening the GPU process is the second lever: keep Chromium's site isolation and GPU sandbox enabled, and avoid disabling the sandbox via --no-sandbox or --disable-gpu-sandbox flags, which would lower the bar for the prerequisite GPU-process compromise at the cost of compatibility with some constrained environments. Applying operating-system-level mitigations that reduce the value of an out-of-bounds read (ASLR, memory tagging where available) limits disclosure but does not fix the missing bounds checks. There is no configuration flag that repairs the geometry validation itself; patch deployment is the only complete remedy.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Electron is Chromium-based, and offscreen rendering (OSR) splits privilege: the GPU process produces compositor frames while the main/browser process consumes them over Mojo IPC. In this design, FrameSubscriber::OnFrameCaptured received a media::VideoFrame whose read-only shared-memory region was mapped independently of the accompanying metadata, and pre-patch code wrapped that mapping in an SkBitmap using row_bytes derived from info->coded_size while sizing the bitmap from content_rect - with no containment check that content_rect fit inside coded_size or that the computed byte size fit inside mapping.size(). The macOS path (osr_host_display_client_mac.mm) had the analogous flaw, taking ca_layer_params.pixel_size and installing pixels over an IOSurface without confirming the surface's byte-per-element, width, height, or alloc size actually backed every row read. The macOS code also called IOSurfaceLookupFromMachPort without checking for a null surface. This is CWE-125 (out-of-bounds read): the root cause is missing validation of IPC-supplied geometry rather than a write primitive, so the realistic outcomes are disclosure of adjacent memory in the captured frame image and denial of service via crash. The upstream fix adds format and shmem-type gating (rejecting anything that is not PIXEL_FORMAT_ARGB backed by a read-only shmem region), a gfx::Rect(coded_size).Contains(content_rect) check, SkImageInfo::ByteSizeOverflowed() guarding against integer overflow in the size computation, and a required_bytes <= mapping.size() bound; the macOS branch adds equivalent IOSurface dimension and allocation-size checks plus a null check. Because the attacker must already control the GPU process, confidentiality impact is constrained to memory the browser process can reach and integrity impact is nil in the assessed vector (S:C/C:L/I:N/A:L).
Know when Electron 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:L/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L
Attacker needs pre-existing code execution in the GPU process (AV:L/PR:H), the inconsistent-geometry trigger is nontrivial (AC:H), and a GPU-to-main-process read crosses a trust boundary (S:C) yielding only memory disclosure (C:L) and crash (A:L).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9, frame data received from the GPU process for webContents.beginFrameSubscription was not fully validated by the main process. An attacker who had separately gained code execution in the GPU process could supply inconsistent frame geometry and cause the main process to read out-of-bounds memory while producing captured frame images, disclosing memory or crashing the application. This issue is fixed in versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
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
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
GitHub Electron versions 1.8.2-beta.3 and earlier, 1.7.10 and earlier, 1.6.15 and earlier has a vulnerability in the pro
Remote code execution in 5ire 0.15.2 and earlier arises because the desktop AI assistant renders Mermaid diagrams with s
Cross-site scripting in DeepChat's Mermaid diagram renderer escalates to full remote code execution on affected desktop
Remote code execution in DeepChat 0.5.1 and below is possible through a cross-site scripting flaw in Mermaid diagram ren
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payl
GitHub Electron before 1.6.8 allows remote command execution because of a nodeIntegration bypass vulnerability. Rated hi
GitHub Electron 1.7.15, 1.8.7, 2.0.7, and 3.0.0-beta.6, in certain scenarios involving IFRAME elements and "nativeWindow
Electron version 1.7 up to 1.7.12; 1.8 up to 1.8.3 and 2.0.0 up to 2.0.0-beta.3 contains an improper handling of values
electron-updater allows for automatic updates for Electron apps. Rated high severity (CVSS 7.5), this vulnerability is r
Cross-origin read bypass in Electron's custom protocol handler exposes sensitive application data to remote pages via fe
Native code execution outside the Chromium sandbox is achievable in Electron prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity
Exploit-DB