EUVD-2026-107392
GHSA-h3v5-h239-pg29
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise GPU process separately
-
DeliveryCraft frame with inconsistent geometry
-
ExploitSend oversized content_rect/pixel_size over Mojo
-
ExecutionMain process reads out-of-bounds building bitmap
-
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 that the target be a macOS Electron application using offscreen rendering (OSR), since the vulnerable code path is in the macOS OSR host display client and video consumer that build paint-event bitmaps from GPU frame data. The decisive prerequisite is that the attacker must have independently achieved code execution within the GPU process (PR:H) in order to supply inconsistent frame geometry (a content_rect or pixel_size not backed by the shared-memory mapping or IOSurface) over Mojo to the main process. Limiting factors that substantially reduce real-world exposure: it is not reachable by a remote unauthenticated attacker, it does not apply to Windows/Linux or to default non-OSR Electron apps, and it depends on first chaining a separate GPU-process compromise - making it a privilege/boundary-escalation step rather than a standalone entry point. |
| Impact | This is a low-priority, defense-in-depth issue rather than an urgent threat, 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, base 3.9 Low) tells the real story: exploitation is local, high-complexity, and requires high privileges - specifically the attacker must have ALREADY achieved code execution inside the GPU process, which the description confirms ('An attacker who had separately gained code execution in the GPU process'). In other words, this is a secondary sandbox-escape/boundary-hardening fix that only matters AFTER a more serious compromise has occurred; it is not an initial-access vector. The scope change (S:C) is justified because the compromised GPU process corrupts memory in the separate main process. Impact is limited to C:L (memory disclosure) and A:L (crash), with no integrity impact (I:N) and explicitly no remote code execution. No EPSS score was provided in the input, so exploitation probability cannot be quantified; however, given the Low severity and the prerequisite GPU-process compromise, widespread opportunistic exploitation is implausible. KEV status is not listed and no POC is referenced, so this is 'no public exploit identified at time of analysis.' The one caveat defenders should verify: exploitation is further gated on macOS AND the offscreen-rendering (OSR) feature being in use, which the raw CVSS does not capture - the actual attackable population is far smaller than a Low AV:L score alone would suggest. |
| Exploit ScenarioDerived | An attacker who has already exploited a separate renderer/GPU-process vulnerability in a macOS Electron app that uses offscreen rendering sends the main process a frame with inconsistent geometry (a content_rect or pixel_size larger than the backing shared-memory region or IOSurface). When the main process builds the paint-event bitmap it reads out-of-bounds, leaking adjacent main-process memory into the paint image or crashing the app. No public exploit code is referenced, and exploitation requires the attacker to first control the GPU process. |
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 macOS offscreen rendering (OSR) path lets an attacker who already has code execution inside the GPU process feed inconsistent frame geometry - a content_rect or pixel_size not backed by the underlying shared-memory mapping or IOSurface - to the main process, which then reads past the end of the mapped buffer while building paint-event images. The result is disclosure of main-process memory contents or an application crash, and exploitation is confined to macOS applications that enable OSR; Windows, Linux, and default windowed Electron apps are unaffected. This is a sandbox/boundary-escalation step rather than a standalone entry point: the assessed vector is CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L (3.9), and attack complexity is high with no public exploit identified at time of analysis. Fixed upstream in Electron 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.
RemediationAI
Vendor-released patch: upgrade to Electron 42.11.6, 43.7.3, 44.4.3, or 45.0.0-alpha.9 as appropriate for your release line (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-h3v5-h239-pg29). The upstream fixes are the commits referenced in PRs 54033, 54036, 54037, 54038, and 54047, which add pixel-format validation, content_rect-within-coded_size containment checks, SkImageInfo::ByteSizeOverflowed guards, and allocation-size comparisons in frame_subscriber.cc, osr_host_display_client_mac.mm, and osr_video_consumer.cc - downstream maintainers who vendor or cherry-pick Electron patches should pull all of them, since any single missing check leaves part of the geometry surface unvalidated. If an immediate upgrade is not possible, the most effective compensating control on macOS is to disable offscreen rendering (set webPreferences.offscreen to false and stop using the paint-event/BeginFrameSubscription APIs), which removes the vulnerable Mojo frame-metadata path entirely; the trade-off is that headless frame capture, offscreen streaming, and custom compositing workflows will need to be re-architected around standard windowed rendering or an external capture mechanism. Additionally, treat GPU-process compromise as a serious incident signal: because this issue requires pre-existing code execution in the GPU process (PR:H), hardening the GPU process (keeping Chromium sandboxing enabled, avoiding GPU-process-hosted native code and unsafe GPU driver paths, and monitoring for GPU-process crashes with anomalous frame geometry logged) reduces the likelihood of the prerequisite condition being met. Note that the crash/DoS aspect (A:L) cannot be mitigated by configuration short of patching, since the same unvalidated geometry drives the out-of-bounds read.
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's offscreen rendering implementation splits frame production and frame consumption across the Chromium process boundary using Mojo IPC. The GPU process renders into either a read-only shared-memory region (FrameSubscriber in shell/browser/api/frame_subscriber.cc, OSR video consumer) or, on macOS, an IOSurface passed by Mach port (shell/browser/osr/osr_host_display_client_mac.mm). The main (browser) process then wraps that buffer in an SkBitmap via SkBitmap::installPixels using a SkImageInfo and row stride derived from geometry fields - content_rect, coded_size, pixel_size, pixel_format - that arrive over Mojo independently of the mapping itself. Prior to the fix, the code trusted those fields: it did not verify the pixel format was PIXEL_FORMAT_ARGB for the shared-memory path, did not check that content_rect was contained within coded_size, and did not check that the byte size Skia would read (computeByteSize(row_bytes)) fit inside mapping.size() or IOSurfaceGetAllocSize(), nor that the IOSurface's width/height/bytes-per-element matched the claimed pixel_size. CWE-125 (Out-of-bounds Read) is the root cause class: a malicious or compromised GPU-process renderer supplies self-inconsistent metadata and the main process reads beyond the buffer boundary, leaking memory into the delivered bitmap or faulting. The upstream fixes add format, containment, overflow (SkImageInfo::ByteSizeOverflowed), and allocation-size checks, and replace a CHECK(false) in the Chromium OSR patch with a graceful DLOG plus early return for non-OSR windows. The security value here is the process-boundary crossing - the GPU process is the more heavily sandboxed process, so a compromised GPU renderer gaining a memory-disclosure primitive in the less-restricted main process matters despite the modest CVSS score.
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 prior code execution in the GPU process (PR:H, AV:L) and must craft precise inconsistent geometry (AC:H); impact crosses to the main process (S:C) causing 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 macOS offscreen rendering was not fully validated by the main process. An attacker who had separately gained code execution in the GPU process could provide inconsistent frame geometry and cause the main process to read out-of-bounds memory while producing paint event 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
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.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
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